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SUMMARY 


A prototype of an expert system has been developed which applies qualitative 
constraint-based reasoning to the task of post-test analysis of data resulting from a rocket 
engine firing. Data anomalies are detected and corresponding faults are diagnosed. Engine 
behavior is reconstructed using measured data and knowledge about engine behavior. 
Knowledge about common faults guides but does not restrict the search for the best 
explanation in terms of hypothesized faults. The system contains domain knowledge about 
the behavior of common rocket engine components and has been configured for use with 
the Space Shuttle Main Engine (SSME). A graphical user interface allows an expert user 
to intimately interact with the system during diagnosis. The system has been applied to 
data taken dining actual SSME tests where data anomalies had been observed. 
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1. INTRODUCTION 


The research described in this report is a continuation of the work performed under a 
previous contract, NAS8-36955, D.O. 58. This, the second, phase of the development of 
a knowledge-based system which assists in post-test data analysis and fault diagnosis of the 
Space Shuttle Main Engine (SSME), builds upon the methodologies devised and explored 
during the earlier contract period. Implementation and software tools are completely 
different, however. 

The Engine Data Interpretation System (EDIS) attempts to assist the data review personnel 
to quickly identify significant data anomalies and to generate explanations for the 
anomalies in terms of abnormal component behavior and underlying faults. The review 
process is time-consuming and repetitive and requires an undue amount of human 
resources, i.e. it occupies too much of the experts’ time. Special care was taken during the 
design to fit EDIS into the current review process without disrupting standard review 
procedures. EDIS can also perform the data analysis and fault diagnosis tasks 
autonomously without intervention by the user. In this mode EDIS might be used to 
produce an independent second opinion. 

EDIS is unusual compared to traditional diagnostic expert systems because it presents its 
questions and results to the user in a manner which requires very little explanation. The 
combination of a special diagnostic mechanism and a state-of-the-art user interface 
strategy make this behavior possible. 

Diagnosis is performed using a qualitative constraint model of the SSME and its 
components. Qualitative parameter values describe data anomalies as positive or negative 
deviations from the norm. Constraints model normal component behavior independent of 
component use within the SSME. The reasoning mechanisms synthesizes a description of 
SSME behavior based on the measured data, the observed anomalies, and knowledge about 
normal and fault behaviors of components. The behavior description makes explicit the 
assumptions about component health and thus generates diagnostic hypotheses. The 
reasoning mechanisms deals naturally with single and multiples faults, with known and 
unknown fault modes, and may be tuned by an experienced user. It also accepts user 
guidance during processing. To some extent, the reasoning process emulates an expert 
who envisions how the SSME is performing using the familiar schematic diagram and 
assumptions about component faults. 

■Hie user interface was designed to make relevant data as well as choices made by the 
diagnostic process immediately visible to the user. Whenever possible the user may change 
the suggestions brought forth by the system and thus redirect diagnostic search. Graphic 
images, menus, and mouse-invoked actions were used throughout the design. 

EDIS does not and cannot claim to automate the review process completely. A much larger 
development effort would be necessary to accomplish this. EDIS, however, should be seen 
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as a prototype of a data review support system in that it explores methods of representing 
relevant expert knowledge which may readily be adapted to changes in the engine, 
methods of reasoning in an expert-compatible style, and methods of user-centered 
mixed-initiative user-system communication. The EDIS project is therefore never finished. 

In the following sections we will first lay out the knowledge representation and reasoning 
methodologies incorporated into EDIS and then describe how to use and maintain EDIS. 
We will close with a note on the state of development of EDIS and a demonstration of the 
performance of EDIS using simple examples. 
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2. DIAGNOSTIC METHODOLOGY 

This section consists of a journal paper which was submitted for publication after receiving 
clearance from NASA. 


MODEL-BASED DIAGNOSIS OF THE SPACE SHUTTLE MAIN ENGINE 

Martin O. Hofmann Thomas L. Cost 

Department of Electrical and Department of Mechanical 

Computer Engineering Engineering 

The University of Alabama in Huntsville 
Huntsville, AL 35899 

Michael Whitley 
NASA-MSFC 
Huntsville, AL 35812 


ABSTRACT 

The process of reviewing test data for anomalies after a firing of the Space Shuttle Main 
Engine (SSME) is a complex, time-consuming task. A project is under way to provide the 
team of SSME experts with a knowledge-based system to assist in the review and diagnosis 
task. A model-based approach was chosen because it can be adapted to changes in engine 
design, is easier to maintain, and can be explained more easily. A complex thermodynamic 
fluid system like the SSME introduces problems during modeling, analysis, and diagnosis 
which have as yet been insufficiently studied. We developed a qualitative constraint- 
based diagnostic system inspired by existing qualitative modeling and constraint-based 
reasoning methods which addresses these difficulties explicitly. Our approach is unique in 
that it combines various diagnostic paradigms seamlessly, such as the model-based and 
heuristic association-based paradigms, in order to better approximate the reasoning process 
of the domain experts. The end-user interface allows expert users to actively participate 
in the reasoning process, both by adding their own expertise and by guiding the diagnostic 
search performed by the system. 

1. Introduction 

Three main engines provide a significant portion of thrust to the Space Shuttle during 
liftoff. Dependable performance of the Space Shuttle Main Engines (SSME) is critical to 
the Shuttle missions. The SSME is a highly complicated device which is stressed to the 
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limit during normal operation. Therefore, each SSME is tested exhaustively for flight 
readiness, and new and improved designs are developed and evaluated frequently. 

A comprehensive data review is performed at NASA Marshall Space Flight Center (MSFC) 
after each firing of a SSME, both after Shuttle launches and after ground tests. The review 
serves to reveal anomalies in the recorded data and, if anomalies are detected, to diagnose 
the underlying engine problem or fault. Shuttle launches occur only infrequently, but a 
SSME is testfired as often as once every three days on one of the five test stands. During 
the test hundreds of measurements are taken up to fifty times per second. The resulting 
bulk of data has to be analyzed at Marshall Space Flight Center within a turnaround time 
of about one day. Analysis is currently performed by a team of experts, some of whom are 
specialists assigned by the SSME contractor companies; others are NASA engineers. These 
experts are also charged with modifying and upgrading the SSME and its components as 
well as with improving and maintaining performance models and data reduction programs. 
Routine data reviews distract and take time away from these more important activities. 
SSME data review and fault diagnosis are good candidates for supporting and augmenting 
expertise-based human activities with a knowledge-based expert system. The tasks are 
repetitive, require expertise in short demand, and do not lend themselves to an algorithmic 
solution. We are developing a knowledge-based system called EDIS (Engine Data 
Interpretation System) which assists the review team in the analysis of engine performance 
data and in the diagnosis of engine faults. 

EDIS incorporates a combination of diagnostic paradigms because neither heuristic rules, 
quantitative models, nor qualitative models alone adequately represent the scope of 
knowledge that human experts apply to the task of SSME data analysis and fault diagnosis. 
Experts are able to intuitively intermix and coordinate reasoning based on these different 
types of knowledge such that each contributes to the solution. The architecture of EDIS 
has been formulated to enable cooperation of several heterogeneous knowledge sources in 
order to emulate the diversity of human expert reasoning. Coordination and cooperation 
of different reasoning paradigms will be described elsewhere. In this paper we present the 
qualitative model-based component of EDIS and the diagnostic reasoning methodology 
which operates on the qualitative model. 

The approach to device diagnosis presented in this paper is rooted in qualitative physics, 
model-based representation of devices, and constraint satisfaction methods. Device 
behavior is represented qualitatively using "qualitative constraints." Constraints model the 
normal (non-faulty) behavior of each component. They are derived by linearizing and 
simplifying physical (thermodynamic) laws. The reasoning mechanism dynamically 
composes device behavior from component behavior, reconciling current case-specific 
measurements with qualitative constraints. Anomalous device behavior gives rise to fault 
hypotheses. Fault diagnosis using constraint-based models is not limited to selecting from 
a set of predetermined faults and does not require assumptions about the number of faults 
present. Knowledge about fault probabilities and component fault modes is only used to 
focus diagnostic search. 
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A large number of sensors provide data on SSME performance. However large the set of 
parameters measured may be, it is nevertheless limited to readings from the installed 
sensors and therefore fixed and incomplete. No additional measurements can be made; 
probing is not possible. Many approaches to expert diagnosis depend on the ability to 
acquire additional data. The methodology presented in this paper is designed to make 
optimal use of available data, measured at locations distributed fairly evenly throughout 
the device, without the need for complete information. Because of incomplete access to 
critical data, cases exist where no definitive diagnosis can be generated, and instead a list 
of possible faults constitutes the final result of the diagnostic reasoning process. 

In the following sections we will first introduce the application domain and point out its 
unusual characteristics. Next we will outline our approach to qualitative constraint-based 
modeling and diagnosis followed by our rationale for selecting this approach. We will then 
describe the methods for implementing the approach, discuss the results, and compare our 
approach to work of other researchers. 

2. SSME Data Review Process 

The EDIS system assists in the analysis of data from tests of the Space Shuttle Main Engine 
(SSME) (Cost & Hofmann, 1990). After each test of an SSME data from several hundred 
sensors are reviewed at NASA MSFC in order to verify SSME performance and to diagnose 
anomalies. A large number of graphs are printed which display parameter values versus 
time. The experts peruse these charts several times: first, to detect anomalies in the level 
or shape of the curves, then, if anomalies have been found, to correlate characteristics of 
other relevant measurements. For example, experts check temperature and flow rates at a 
pump inlet if perturbations in the pressure readings were detected at this site; they also 
follow anomalous readings along the fluid or gas path through the engine. 

Separate sets of charts are produced for different stages of the SSME firing, i.e. the startup, 
main stage, and shutdown stage. During main stage the SSME settles into steady state 
during time intervals of constant commanded power level. The first version of EDIS is 
limited to analysis of steady-state data during mainstage operation. Figure 1 shows a 
typical chart which depicts the shaft speed of the low pressure fuel turbine. Steady-state 
conditions can be observed from about 100 seconds to 300 seconds and from 320 to 450 
seconds after ignition. The power levels are 104% and 100%, respectively. Like most 
other charts it contains two curves, one for the current test and one from a previous test 
which the new data are compared against. Comparison charts such as this one are used to 
identify anomalies in the current test data. A numerical power balance model which 
predicts critical engine parameter values exists, but it is not used for anomaly detection 
because it is not reliable enough. The quantitative model also cannot simulate individual 
component behavior, and its fault simulation capabilities are limited. 

Testing an SSME is very complicated, labor-intensive, and expensive. It is not possible to 
repeat a test just to get more or different measurements. Therefore the problem of 
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selecting optimal additional points to probe does not arise. To offset the lack of additional 
measurements an unusually large number of parameters is measured during each test and 
made available for analysis. A diagnostic technique was developed for ED1S which 
performs well with a large but fixed number of parameter values. 


XX TEST 6 2 LPFP SPD 

AA TEST 6 1 LPFP SPD 



FIGURE 1. TIME FROM START COMMAND - SECONDS 


Most first-generation diagnostic, expert system use heuristic rules to generate and test 
hypotheses. Heuristic rules are inadequate for SSME diagnosis because of the complexity 
of the SSME, because the SSME is continually being modified, and because faults arise with 
low frequency and high degree of variation. Few faults can be recognized by their 
symptom patterns. In other words, although the review process is routine, the anomalies 
and faults encountered are not. 

There exist many aspects of the SSME data review process which have been or will be 
addressed in the EDIS project but are not discussed in this paper. For example, the review 
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behavior of a number of thermodynamic components are supplied with EDIS. Any 
particular device is described in terms of its components and their interconnections. 
Definition of device structure and component parameters, e.g. efficiency or friction 
coefficients, configure the model of a particular device, see Figure 3. 


Generic Thermodynamic SSME Component List, 

Component Models SSME Component Connectivity, 



Teat'Speelllo 
SSME Model 


FIGURE 3 


3.1 MODEL 

Behavior is modeled by incremental qualitative constraints (IQCs) on system parameters. 
The characteristic parameters of the medium moving through the thermodynamic device 
constitute the set of system parameters. Typical parameters are pressures and temperatures 
of fluids or gases and the rotational speed of pumps and turbines. Constraints are 
incremental because they describe behavior as change or deviation from normal values. 
The incremental formulation linearizes and simplifies the constraints. Constraints are 
qualitative because they classify parameter values into three categories: normal, high, and 
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Constraints express qualitative proportionality between deviations of parameter values from 
the norm, assuming correct device behavior. Constraints are derived from mathematical 
system models, but unlike Iwasaki and Simon (Iwasaki & Simon, 1986), who derive a 
qualitative model from the differential equations describing system dynamics, we start with 
steady-state equations of energy and mass equilibrium. The term "behavior" thus denotes 
the ordinal interrelations of system parameters in steady-state, instead of an account of the 
dynamic changes in parameter values. Our type of analysis is labeled "comparative statics" 
by Kalagnanam, Simon & Iwasaki (1991) in a recent review of qualitative reasoning. 
Incremental deviations can also be represented quantitatively. Govindaraj (1987) reports 
the use of a quantitative deviation model to simulate a complicated marine steam power 
plant. Biswas, Hagins & Debelak (1989) formulate a quantitative process model for a fluid 
system. Our primary model is qualitative. 

Constraints describe local behavior, i.e. they describe the interrelations of parameters 
associated with each particular component. Parameters are associated with a component 
if they are defined at one of the terminals of a component, e.g. its inlet, outlet, or shaft, 
or if they describe medium state within a component. IQCs are thus an example of 
component-centered qualitative modeling in contrast to process -centered modeling 
developed by Forbus (1984), which decomposes the device model into processes instead 
of components. A process definition collects descriptions of the influences on a substance 
mediated by all the components it is in contact with. In the SSME, where a substance, 
such as the engine fuel, is engaged in many processes at the same time, a 
component-centered modeling approach leads to a more satisfactory decomposition. For 
each component, however, behavior is described as a process which obeys thermodynamic 
conservation laws. Global behavior is generated by simultaneously satisfying the 
constraints imposed by all components. Parameters defined at the terminals of components 
constitute the linkage between component behaviors since their values have to satisfy the 
constraints of two or more connected components, see Figure 4. 


shared/coupiing parameters 



FIGURE 4 
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For example, the behavior of a pipe is characterized by an energy conservation equation 
and a mass conservation equation between the pipe inlet (index 1) and the pipe outlet 
(index 2). 


vi 

— + h. 
2 8 1 

Pi *2 Pi 

+ - - Km = TT + *2 + “ 

Y 2g y 

(la) 


V 2 L 

=fj~ j- 

2 g D 

(lb) 


Yi^i^i = Y2^2*2 

(2) 


V = average fluid velocity 

Vj = fluid velocity 

g = gravitational constant 

h = height 

p = pressure 

y = density 

L = pipe length 

D = pipe diameter 

f = friction coefficient 

Aj = pipe cross-sectional area 

After linearization and simplification equations (1) and (2) reduce to (3) and (4) 
respectively. The delta operator (A) indicates incremental (small signal) change and K is 
a constant which depends on the operating point, the pipe dimensions, and the friction 
coefficient. 


A(p, -p 2 ) = K • AF (3) 

AKj = AK 2 (4) 

The essence of these equations, which is captured by IQCs, is that the pressure difference 
between inlet and outlet is proportional to the velocity, and that the input velocity is 
proportional to the output velocity as long as the pipe is operating correctly. Faults which 
could invalidate the constraints are pipe leaks and obstructions, for example. 

It has been shown by Kalagnanam et al. (1991) that the ordinal properties of the involved 
quantities do not change even under such strong simplifications as long as the simplifying 
transformations are monotonic. Our simplifications and transformations from quantitative 
to qualitative models therefore preserve relative magnitude of parameter values. If, for 
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example, the qualitative model predicts an increase in value then the quantitative model 
(if it existed) would also predict an increase. Invariance of ordinal properties in essence 
guarantees that qualitative values are predicted correctly by IQCs. 

3.2 DIAGNOSIS 

In the presence of faults there will be no parameter value assignment which satisfies all 
constraints. Davis R. (1984) describes "constraint suspension", a technique which finds the 
constraint (or constraints) which, if suspended, eliminate all conflicts. The procedure is 
basically trial and error and demands that a complete analysis be made for each hypothesis. 
A number of other approaches have been reported which will be discussed when 
appropriate in the following sections. 

EDIS uses a constructive diagnostic paradigm. EDIS attempts to find the most appropriate 
explanation of the observed symptoms. An explanation of behavior indicates values for all 
critical parameters and assertions about health states of components. Such an explanation 
is called a "scenario." Faulty components may exhibit unconstrained behavior, all other 
components must obey their behavior constraints. Each scenario which takes all measured 
data into account and satisfies all constraints except for those imposed by components 
considered faulty generates a fault hypothesis. The hypothesis states that those and only 
those components whose behavior constraints were disregarded are the cause for the 
observed malfunction. Finding the qualitative behavior of a system is called "envisioning" 
in the qualitative modeling literature, e.g. De Kleer & Brown (1985), Forbus (1988). In 
general, envisioning deals with dynamic behavior of devices described as sets of states and 
state transitions. EDIS envisions steady^state values of critical engine parameters, i.e. 
engine states, but no state transitions. 

Envisioning scenarios is a constraint satisfaction problem. However, constraint satisfaction 
alone is not powerful enough to perform diagnosis. Consider a faulty SSME and a set of 
measurements which renders the fault observable. If all constraints are enforced, no 
consistent assignment of values to constrained parameters exists. Diagnosis consists of a 
search for those constraints which, if revoked, permit a consistent value assignment. There 
are thus two levels of search involved in diagnosis: search for the violated constraint or 
constraints, which identify the failed component, and search for a consistent value 
assignment given this fault, i.e. constraint satisfaction. Both types of search are 
computationally intensive and are supported by knowledge about normal and fault 
behavior of components. 

There are, in general, a vast number of scenarios which fit the measured data and satisfy 
a subset of component constraints. A diagnostic strategy has been defined which attempts 
to select a small number of "good" scenarios, i.e. plausible fault hypotheses. Scenario 
quality is determined from a number of factors which effectively characterize how likely 
a hypothesis is with respect to other hypotheses. Diagnosis is viewed as search in a space 
of all scenarios for the scenario which best explains the symptoms. SSME diagnosis is a 
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domain complex enough to render enumeration and subsequent selection of hypotheses 
impossible. According to the problem classification scheme described by Stefik, Aikins, 
Balzer, Benoit, Bimbaum, Hayes-Roth & Sacerdoti (1983) we are dealing with a big, 
factorable solution space calling for a step-wise generate and test methodology. Therefore, 
EDIS attempts to sequentially accommodate the constraints contributed by one component 
at a time, thereby creating partial scenarios. Partial scenarios are evaluated and compared 
against each other at each step. 

Observed anomalies contribute to the envisionment of scenarios through a process of 
counterfactual reasoning (Adams 1975), which either suspends the constraint and declares 
the component faulty or puts the blame on anomalous data on the component interfaces. 
Anomalous values of parameters associated with a component do not by themselves imply 
a fault of this particular component. Some kinds of anomalous behavior may be due to a 
shift in operating point caused by a fault in some other part of the SSME. Full knowledge 
of all critical parameters would be necessary to judge the health of individual components. 
In reality, assumptions must be made and their consequences tested against all available 
data and knowledge of SSME behavior. 

Generation of a scenario simulates device behavior since it transforms the implicit 
representation of component behavior as physical constraint laws into value assignments 
for parameters which characterize states and behaviors of components. Accounts of device 
behavior can be used to justify fault hypotheses to the end user. 

A qualitative model, regardless of whether it is a constraint model or not, is less precise 
than a quantitative model. Precision becomes important during constraint testing when 
the relative strengths of opposing changes cannot be predicted. Two kinds of errors can 
be made by the scenario generator. It can assume that opposing influences cancel out 
when in fact they do not, i.e. the component is considered to be working correctly when 
it is in fact faulty; or the scenario generator can assume that a constraint is violated when, 
in fact, the component is working correctly. In the first case scenarios may exist which do 
not contain an existing fault, in the second case scenarios will contain too many faults. 
Our current approach is to generate separate scenarios for both assumption and to use 
more accurate, e.g. quantitative constraints, to test the validity of assumptions whenever 
possible. 

EDIS operates as an assistant to the user. More difficult to implement than an autonomous 
expert system, an assistant system is better suited for use by domain experts who are 
expected to augment system expertise with their own experience in the analysis task. Also, 
the broad scope of this project and the uncertainty associated with the analysis proce ss , 
which arise from the diversity of knowledge and from the limitations on data collection and 
process characterization, favors a system structure which is open to user guidance. For 
example, the system accepts user-generated fault hypotheses and elaborates and evaluates 
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them like hypotheses generated by the system itself. A graphical user interface which 
supports mixed-initiative processing and offers direct manipulation of diagnostic plans and 
hypotheses is under development. 

4. Rationale 

A model-based approach was chosen as the main diagnostic paradigm because it provides 
a declarative formalism for specifying domain knowledge which can be easily updated and 
improved. A model-based system can more readily be adapted to changing device 
configurations. Changes to SSME configuration keep happening since improvements to its 
design are still actively sought. In general, our approach is applicable to a variety of liquid 
fuel engines and fluid systems in general because the knowledge about device behavior is 
stored in reusable component models. 

A model-based domain knowledge representation facilitates explicit formulation of 
reasoning strategies. Diagnostic reasoning can be subdivided into discrete tasks which are 
scheduled by an intelligent strategy module. The device model forms the basis for 
coordinated performance of the task modules. Data, strategic plans, and intermediate 
diagnostic results, such as a list of currently active hypotheses, can be accessed and made 
available to user inspection. Users can more easily understand and be involved in decisions 
and choices made by the system. Qualitative formulations also help to create reasoning 
paths which are more easily understood and directed by a user as compared to heuristic 
rules or quantitative approaches using equation solvers. 

Models using constraints naturally represent component behavior at a detailed physical 
level independent of component use or function within a device. Constraint-based models 
support behavior simulation as well as verification. A description of device behavior using 
a constraint model does not presuppose a particular diagnostic methodology. Diagnosis 
based on a constraint model can operate without any fault assumption, e.g. GDE (de Kleer 
& Williams 1987), with fault assumptions but without models of fault behavior, e.g. Davis 
R. (1984), or can operate generatively, like in EDIS. Generative methods, i.e. methods 
which envision behavior, are computationally more expensive, but envisioned behavior is 
a useful byproduct of diagnosis because EDIS uses envisioned scenarios to explain and 
justify hypotheses. In order to reduce complexity, EDIS exploits restrictions on possible 
fault behavior options imposed by physical laws and domain heuristics. For example, 
energy and substances cannot be spontaneously created, and in a high pressure fluid 
system, such as the SSME, fluid can leak out but cannot be added to the system from the 
environment. 

Compiled causal model representations also fail to adequately capture the intricate relations 
between critical parameters. Compiled causal models suffer from the same shortcomings 
as heuristic rule-based representation. They do not easily adapt to changes in 
configuration, and they cannot easily cope with the lack of direction of causal influence 
between processes and parameters. Constraints, however, can easily represent 
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Quantity- 1 Relational-Operator Quantity-2 


The two relational operators are 
p ... "is proportional to" and 
ip .. ."is inversely proportional to". 


COMFONBVT 





GAS_TURBINE HYDRAUUC_TURBINE 
Figure 5: Component Hierarchy (partial). 

A quantity is either a state parameter of the fluid or gas, such as pressure, a derived 
parameter, such as pressure difference, or an explicit measure of energy. We allow only 
two-place relations in order to simplify reasoning. More complex relations can be 
represented by introducing derived parameters where necessary and explaining their 
composition with normative constraints. 

The semantics of fundamental and normative constraints and of auxiliary relations differ. 
A fundamental constraint captures an energy balance which must hold when the 
component is operating correctly. Faults, in general, are assumed to introduce losses and 
to invalidate fundamental constraints. 

A normative constraint relates a derived quantity which appears in a fundamental or 
normative constraint to measurable quantities. Since this derived quantity will be normal 
or "constant" during normal operation, but may deviate from normal in the presence of a 
fault, it is called a "pseudo-constant." Note however, that a change in a pseudo-constant 


19 



by itself does not incriminate a specific component, since its value could have shifted due 
to a change in operating point. Normative constraints must hold only as long as the derived 
quantity they depend on remains constant. 

Auxiliary relations describe how a change in a pseudo-constant is reflected in the quantities 
of the normative constraint. An auxiliary relation thus couples a normative relation to a 
fundamental relation via its pseudo-constant quantity. Normative constraints may be 
coupled to a fundamental constraint through a chain of other normative constraints in 
order to deal with more complex cases. 

For example, the behavior of a pipe is characterized by fundamental constraints (5) and 
(6), which are equivalent to equations (3) and (4) above. 

p-diff p V (5) 


V,/> V 2 


( 6 ) 


p-diff = pressure difference 

Equation (3) asserts that a small change in the difference between fluid pressures measured 
at both ends of the pipe is proportional to a change in the velocity of the fluid. The 
constraint was derived from a fluid energy balance, given by equations (la) and (lb), 
neglecting possible differences in height and diameter of the pipe ends. Equation (4) 
indicates that a change in flow rate at one end must be proportional to a change at the 
other end. It was derived from a mass conservation law given by equation (2). The pipe 
has one normative constraint, defined by equation (7). 

Pi P P 2 (7) 

Constraint (7) holds (at least) as long as the pseudo-constant "p-diff' remains constant. 
One can observe that the normative constraint captures a superficial rule-of-thumb analysis 
of pipe behavior. 

Auxiliary relations are applied when a pseudo-constant has (or is suspected to have) 
changed and its changes have to be related to changes in the parameters of the normative 
constraint. In the example the auxiliary relations for p-diff are given by equations (8) and 


(9) and for V by equations (10) and (11). 

P iP P-diff (8) 

p 2 ip p-diff (9) 

V, P V (10) 

V 2 p? (11) 
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still exist. If contradictions are found, only faulty behavior is possible. This last rule 
eliminates creation of invalid hypotheses; it is equivalent to hypothesis testing. All possible 
and valid behaviors are generated except for physically impossible ones. Therefore, an 
additional fault hypothesis is generated at each step. 


At the end of the reasoning process the most promising complete scenarios are presented 
to the user as candidate solutions. Each scenario indicates which component or 
components might have failed and how the failure has affected component behavior. 

Next, we will present an example for a single step of the envisionment process. We will 
use a pipe as the component under consideration since we have already defined its 
behavior. Assume that a partial scenario exists which determines input pressure and 
velocity. The task is then to create all possible scenarios augmented by information derived 
from the behavior of the pipe, i.e. its average velocity, output velocity, pressure difference, 
and output pressure, we will demonstrate the development of a subset of behaviors. Table 
1 lists all possible behaviors. 


Table 1 

Possible Pipe Behaviors Given pj = 1, Vj = n 
(1 = low, n = normal, h = high) 


CASE 

I DERIVED VALUES 

No. 

Type 

v 2 

V 

p-diff 

P 2 

1 

normal 

n 

n 

n 

1 

2 

faulty 

i 

i 

i 

h 

3 

Canity 

i 

i 

i 

n 
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faulty 

i 

i 

h 

i 

5 

• 

i 

i 


i 

6 

i 

i 

n 

D 

7 

n 

n 

h 

l 

8 

n 

n 

1 

D 

9 

n 

n 

1 

h 

10 

i 

n 

n 

1 

11 

i 

n 

i 

h 

12 

i 

h 

i 

n 

13 

1 

i 

n 

h 

i 
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We will use the constraints associated with the pipe to predict values for the unspecified 
parameters. First, we will derive normal (non-faulty) behavior. Constraint (6) determines 
the output velocity to be normal. Auxiliary relations (10) and (11) agree that the average 
velocity should be normal also. Since constraint (5) predicts that the pressure difference 
is normal we can use the normative constraint (7) to derive the output pressure to be low. 
This is case 1 in Table 1. 

If fundamental constraint (6) were violated, the output velocity would be low. It cannot 
be high since fluid cannot be added to the system. This is a case where a potential fault 
behavior is eliminated because it violates basic, domain-wide assumptions. The average 
velocity could be normal or low depending on the size of the deviation. In each case we 
need to investigate the cases for constraint (5) being complied with or violated. In the 
case where the average velocity is low and constraint (5) is complied with, the pressure 
difference will be low and the output pressure can thus be high or barely normal. These 
two cases are numbered 2 and 3 in Table 1. 

The predictions generated in this step are added to the parent scenario (the scenario which 
supplied values for input pressure and velocity), and thus thirteen successor scenarios are 
generated. If no further data are available, each scenario is evaluated and the best ones 
are extended further. Evaluation would prefer case 1, because it requires no new fault 
hypothesis. Cases 4, 5, 10, and 13 would also be ranked high, because they predict low 
output pressure and flow which is consistent with a common pipe fault, a leak. 

If additional data, i.e. measured values of parameters, are available, some scenarios can be 
eliminated. If, for example, the output pressure is known to be low, then cases 2, 3, 6, 8, 
9, 11, and 12 are impossible and the number of cases to be considered has been halved. 
If it is known to be normal, then only cases 3, 6, 8, and 12 survive. Here, the normal case 
has been eliminated. Therefore, in die context of this particular parent scenario the pipe 
must be considered faulty. Note that in general there will be several parent scenarios, each 
leading to different conclusions. 

The diagnostic process terminates after all components have been analyzed. If, in the case 
described above, the faulty pipe is the only fault required to satisfy all other constraints 
(using any one of its possible fault behaviors), then the completed scenario would raise the 
hypothesis that the SSME is malfunctioning because the pipe is faulty. If a complete 
scenario contains fault behaviors for two or more components, then the hypothesis implies 
multiple concurrent faults. Thus, no special procedures are necessary to deal with multiple 
faults. Scenarios which hypothesize multiple, but common, faults compete directly with 
single, but unusual, fault hypotheses through the heuristic evaluation function. 


23 



7. Implementation 


At the beginning of the project several expert system shell products were evaluated. 
Important selection criteria included power of representation and inference mechanisms, 
ease of creating a custom user interface, portability between various hardware platforms^ 
and ease of integration with existing and future software components. Shells which 
contained support for the object-oriented paradigm, i.e. support for classes, defaults, 
inheritance, and instantiation, were preferred. The selected shell also had to run on a 
personal computer. Our evaluation ranked NEXPERT-Object first and KES second. 
However, due to budget constraints we selected KES for the initial phase of the project. 
KES provides backward chaining rules, data driven demons, and a class/member 
(object-oriented) representation formalism. In addition we purchased a subroutine package 
which contains support for mathematical functions and graphical data presentation. These 
subroutines were integrated with KES and provide the user interface framework. KES itself 
was embedded into a C main program which manages execution of EDIS system tasks. 


After encouraging results prompted us to proceed to a second development phase, we 
decided to change to more powerful tools. We chose NEXPERT as the expert system shell 
and Toolbook as the user interface environment, both of which run under Microsoft 
Windows. NEXPERT and Toolbook are linked through function calls and handler scripts 
using the Dynamic Link Library mechanism of Microsoft Windows. 

Currently, we are concentrating on mainstage steady-state anomalies due to, for example, 
turbo-machinery performance degradation or pipe leaks. 

8. Discussion and Future Work 

The EDIS system is still in a prototype state and its performance cannot be formally 
evaluated yet. Instead of discussing results we will contrast our approach to related 
methods reported in the literature. We believe that mixing diagnostic paradigms and using 
incremental qualitative constraint models constitute a novel and effective way of diagnosing 
complex thermodynamic systems such as the SSME. EDIS attempts to solve a difficult 
problem in a manner which is compatible with human expert behavior. The overt behavior 
of the process by which diagnosis proceeds from symptom detection to fault identification 
has rarely before been the focus of attention. Previously, only the characteristics of the 
process, such as fault coverage, completeness, and efficiency, had been considered. The 
only exceptions were concerns for the order of questions and additional measurements. 
An additional benefit of the EDIS methodology is that explaining the rationale behind 
diagnostic behavior has become easier because system (EDIS) behavior is modeled after the 

behavior of human experts and meta-reasoning about goals and tool choices is made 
explicit. 


A review of recent publications reveals that applications of expert systems to SSME 
behavior analysis have been largely focused on real-time detection of malfunctions and 
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health monitoring (Perry, 1988, Gupta and Ali, 1988). Neural networks (Luce & Govind, 
1989, Whitehead, Kiech & Ali, 1990, Luce & Govind 1990) and signal processing 
techniques (Norman & Taniguchi, 1988, Walker & Baumgartner, 1990) have lately been 
proposed and developed because they accelerate processing and promise to recognize 
anomalies and imminent failures fast enough to avert dangerous consequences. There is 
no need or time to interact with a human user. EDIS, on the other hand, was designed to 
operate off-line in cooperation with human experts. Emphasis has been placed on smoothly 
integrating EDIS into the review processes. The ability to explain reasoning and the state 
of diagnosis and to accept directions from users are important. 


De Kleer et al. (1987) have presented GDE, a method for diagnosing single and multiple 
faults in systems which can be modeled by interconnected modules, each characterized by 
constraints between input and output parameters. Essentially the same method has also 
been proposed by Reiter (1987) except that his derivation is based on formal logic. GDE 
predicts values for device parameters given some known values, e.g. measured or input 
values, by propagating the known values through the component interconnections and 
constraint expressions. Note that constraints must be non-directional, i.e. the system must 
be able to reason from inputs to outputs as well as from outputs to inputs. Davis R. 
(1984), for example, supplies "simulation" and "inference" rules for forward and backward 
propagation, respectively. Constraint propagation mechanisms in general are discussed by 
Davis E. (1987). 

The diagnostic paradigm exemplified by GDE is very powerful but some caution is 
appropriate before recommending it for every diagnostic application. De Kleer et al. 
(1987) point out that complete prediction of component and system behavior is currently 
beyond the state-of-the-art. The SSME is a good example of a complex dynamic system 
whose behavior is very difficult to model and to predict. Also, GDE relies on the ability to 
take additional measurements until the fault or faults have been uniquely identified. GDE 
works well when all data at a given location can be measured. EDIS is adapted to deal 
with many pieces of incomplete information located quasi-randomly within the structure 
of the SSME. Also, the results gained from propagation can be further manipulated using 
different diagnostic paradigms, such as heuristics, quantitative simulation, or simply user 
input. The qualitative reasoning methodology used by EDIS lends itself to integration in 
a larger diagnostic framework, which is important when satisfactory reasoning behavior 
cannot be generated using one paradigm alone. 

Reasoning about SSME behavior is similar to analyzing electronic circuits at the component 
level since fluid systems and electric circuits can be modeled by structurally equivalent 
equations. Stallman & Sussman (1977) presented a constraint-based approach to circuit 
analysis. Fluid systems have to cope with two additional problems. The structure of a 
fluid system, especially a high pressure system like the SSME, can easily experience 
structural changes, i.e. leaks. Leaks correspond to short circuits which are usually 
acknowledged as being hard to diagnose. The reason is that the device structure has 
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changed. Also, power sources are more complex in fluid systems. Pumps usually supply 
constant power to the system, characterized by a constant product of pressure difference 
times fluid velocity. These differences make it hard to apply the mechanisms developed 
for electric circuits directly to SSME diagnosis. 

Extensions to the work presented in this paper can follow several directions. Analysis of 
dynamic anomalies, such as drifts, steps, and spikes, in parameter values can be included 
into EDIS. The SSME is known to experience such anomalies. The qualitative constraint 
representation will have to be augmented in order to accommodate dynamic behavior, and 
temporal reasoning capabilities will have to be added. A formalism like Qsim (Kuipers 
1985) augmented with temporal information, e.g. time instants and interval duration, 
might prove to be sufficient. 

Further methods and tools representing additional paradigms could be added to the 
reasoning framework of EDIS. Case-based reasoning would address the reoccurrence of 
similar faults. Case-based reasoning could supplement qualitative reasoning to envision 
diagnostic scenarios. 

Better, more efficient ways of searching the space of possible behaviors could be explored. 
For example, the search does not necessarily have to follow structural linkages but could 
execute opportunistically, concentrating on components which are likely to contribute 
essential information to the solution. The search could be implemented in a parallel 
fashion or even cast as a simulated annealing problem if a suitable energy function is 
formulated. 

Facilities which implement limited self-improvement or learning could be added. For 
example, newly discovered component failure modes could be included into the set of 
known modes. After that, EDIS would consider scenarios more likely which invoke the 
stored failure mode. Newly revealed symptom/fault associations could be added to the 
heuristic rules and used as shortcuts in subsequent diagnoses. 
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3. USER GUIDE 


This section describes the interaction between user and system during a diagnostic 
consultation. Input options and output formats are explained. We also illustrate the 
consequences of user choices on system behavior and performance. It should be noted that 
EDIS operates primarily as an assistant to an expert user and as such can be directed to 
operate according to user-defined reasoning paths. We start with a description of the files 
which have to be provided for EDIS to operate correctly. Some of the information given 
is overly restrictive; system capabilities depend to a large degree on configuration files 
which may be changed by a knowledgeable user. Section 4, "Developer Guide", will 
describe system configuration. 

The main idea behind the qualitative reasoning system is to generate an account of the 
behavior of the SSME in terms of its parameters and (possibly) its faults. Behavior is 
characterized by qualitative values of parameters (normal, high, and low) and by fault 
hypotheses, e.g. pipe leaks, pump efficiency drops, etc. Fault hypotheses are derived from 
specific behaviors, i.e. parameter assignments. Since too few parameters are measured by 
sensors, EDIS generates additional values to complete the behavior model. Generation of 
values is constrained by thermodynamic laws applicable to particular components but to 
a large part remains guesswork, in particular at the beginning of diagnosis when local 
measurements have not yet been propagated through the SSME structure. EDIS tries to 
pick the most promising choice from the available behavior alternatives and propagates its 
effects to the rest of the components. Obviously, false starts are possible which lead either 
to conflicts with other measurements or to highly improbable fault assumptions. In both 
cases EDIS will back up and select another alternative. Wrong guesses will never cause 
EDIS to completely discard the correct answer but it may take longer to find it. There may 
also exist several equally satisfying diagnoses, at least from EDIS’ point of view, which may 
be generated in an order which depends on the choices made. Choices are controlled by 
heuristic evaluation functions which attempt to emulate the reasoning of a human expert. 
See the section on performance tuning for more information. 

3.1 Preparations Before Running EDIS 

EDIS reads files to 


- configure the engine (SSME) 

- configure the sensors 

- provide test data 

- provide comparison data 

- provide limit data 

- set fault probabilities 


[required] 

[required] 

[required] 

[required] 

[at least one type] 
[optional] 
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An end user has to prepare the test and comparison data files only. All other files do not 
normally change from test to test. All these files currently reside in the same directory as 
the EDIS source files. The list of sensors need not be changed in case of sensor failures; 
missing values present no problem. The configuration has to be updated to recognize new 
sensors which provide additional measurements, however. Limit data may be 
changed/updated when required. If you need to check that you have all the necessary files, 
refer to the "Installation" section later in this document. 

Currently, only those parameters which are collected in the 2-sigma data base can be read 
into EDIS. They are listed in Appendix C. To generate a data file for a particular test, 
extract data the same way as it is done to include new data into the 2-sigma data base, 
using program PIDEXT. You need to save the resulting fixed-format ASCII file under any 
name ending in extension ".DAT'. An example file (A1614.DAT) is listed in Appendix D. 
Create two such files: one for the current test data and one for the data from the test to 
compare against (most likely the previous test of this engine). Note that the comparison 
data are not yet used during diagnosis because we did not incorporate limits for the 
difference between test and comparison values. 

3.2 Running EDIS 

3.2.1 Cautions 

1. To exit from EDIS, ALWAYS choose the EXIT option from the EXIT menu or click on a 
button labeled STOP, EXIT, etc. 

2. When something goes wrong with NEXPERT, EDIS will lock up your computer and you 
have to reboot. This may happen after a reconfiguration if you are not careful. Any error 
or warning message from NEXPERT will cause this, e.g. missing files, compilation 
warnings, if the NEXPERT authorization module is not plugged in, etc. 

3. When you are using the development versions of TOOLBOOK and/or NEXPERT you have 
the power to change ANYTHING. Refrain from doing this unless you are an experienced 
developer. 

4. If you iconify the EDIS window you will see a NEXPERT icon. This is the NEXPERT 
session which is controlled by EDIS. You can open it and inspect system state if needed 
(recommended only for experienced users). 

5. EDIS uses only one value for each parameter. This value is currently taken at 104% 
power level and maximum HPFT discharge temperature. 
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3.2.2 Conventions 


A user interacts with EDIS by clicking on buttons, selecting items from menus, filling 
blanks, and clicking on graphical objects. 

Buttons are green if they represent normal choices, e.g. normal modes of operation 
acceptance of system suggestions, or simply continuation of processing. Buttons are red 
if they stop or change the operation of EDIS. Yellowish brown buttons can be clicked for 
optional activities, e.g. requesting more information. 


Fields which have yellow headers with blue text require input from the user, e.g. entry of 
names. Green fields with blue text present information on the progress of EDIS 
White fields with red text are displayed during periods of silent system operation. 

3.2.3 Invocation 

Invoke Microsoft Windows 3.0 and click on the EDIS icon. This executes the command 


< path > \TOOLBOOK\TOOLBOOK. EXE ..\NEXPERT\NXPTBK\EDIS.TBK 


where <path> represents the directory path on your machine. 


3.2.3. 1 Introductory Screen 

First, TOOLBOOK is loaded and an introductory screen appears. Click on the green START 
button. Now NEXPERT and the SSME configuration will be loaded. NEXPERT displays 
tte manes of the knowledge-base files being loaded. When done, you enter a screen where 
EDIS asks for the test and comparison data file names. 


3.2.3.2 File Entry Screen 


names , of mes y° u orated during the preparation step followed by 
< RETURN > omitting the extension".DAT'. To make corrections you may return the cursor 

to a field by pressing < RETURN > or by clicking the mouse button in the field. EDIS will 
give an error message if the files do not exist. In that case you can either stop EDIS or 
lcomfy it, open a DOS window, create the files, restore EDIS, and continue normally. 

There are three options listed which you may choose by clicking on the box to their left 
Only the middle option is implemented at this time. It serves to reformat the 2-sigma limit 
ffle so that it can be loaded quickly by NEXPERT. Use this option after a new 2-sigma limit 
tile has been created (check the Developer Guide for details). 
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Two additional buttons are provided which let you choose between assistant and 
autonomous mode of operation. In assistant mode (the default) the user may interact with 
the system during diagnosis and must be present. In autonomous mode EDIS will work 
quietly until a diagnosis has been found. In the following it is assumed that the system is 
operating in assistant mode. 

Now click the Continue button to load the data files and load the SSME configuration. 
This may take a while. EDIS first loads the test and comparison data into TOOLBOOK 
(because only TOOLBOOK can load the fixed ASCII format) and then transfers the data to 
NEXPERT. NEXPERT then loads the SSME configuration and 2-sigma limit data and 
immediately executes the anomaly detection algorithm. Three types of limits may be 
supplied and at least one has to be supplied. Currently, this is the 2-sigma limit file. In 
the future, heuristic limits for the difference between current and comparison test data may 
be supplied and also absolute upper and/or lower limits for data may be added. Note that 
the 2-sigma limits currently in use are too permissive to find some anomalies. The example 
case will illustrate this. 

3.2. 3.3 Wait Screen 

Before you get to the Anomaly List Screen a "Wait" Screen is displayed so can can see that 

something is happening. Just watch as the messages change and wait for the next screen 
to appear. 

After this screen some strange glitches appear, i.e. irrelevant screens being displayed for 
a moment, just ignore those please. I have not been able to get rid of that. 

3.2.3.4 Anomaly List Screen 

After anomaly detection is complete, a screen is displayed which lists those parameters 
which were found to be anomalous, i.e. they were either too high (exceeded the +2-sigma 
limit) or too low (were below -2-sigma limit) as measured from the average value. Since 
anomaly detection is imperfect, the user may select measurements to add to or delete from 
the list of anomalies. To add, click on the ADD PARAMETER button and wait for a list of 
measurements to appear. Then scroll the list to the desired parameter and click on it (may 
require two clicks). Now select HIGH or LOW as new qualitative value. Click on the 
DONE button when done. To delete, click on the DELETE PARAM button and click on an 
entry in the list of anomalies; it will disappear. When finished deleting click on FINISHED 
Note that you can only undo a delete action by explicitly re-adding the parameter to the 
anomaly list as described above. 

You can immediately start diagnosis by clicking the green Diagnosis button or you may 
elect to go to a screen which displays a schematic of the SSME (button "Schematic"). This 
screen allows to inspect measured values of engine parameters and to see measured data 
plotted against comparison and limit data. 
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3.2.3.5 SSME Schematic Screen 


A simplified schematic of the SSME is displayed, see Appendix E. The schematic does not 
quite fit on one screen. Scroll bars are provided to view the clipped portions of the 
drawing. Components which have anomalous parameters associated with them are drawn 
in red, all others in black. If an anomalous parameter is associated with several 
components, e.g. a pressure at the output of a pump and the input of a pipe, only one 
component is marked in red. We chose the more "important" component, i.e. the pump 
instead of the pipe, in most cases. This can be changed in the configuration file, see below. 

If you click on a component (NOTE: click on a line, not whitespace) a scrollable list of 
parameter values will be displayed. The numbers indicate the current test values. 
Anomalous values are displayed in bold print. If you click on one of the entries a 
comparison chart is drawn which shows the relative values of current, comparison, and 
2-sigma limit data. They are labeled with their numeric values. Current test data are 
drawn in green, comparison data in blue, and 2-sigma limit data in purple. Thus it is 
possible to inspect the numeric values of all currently available data. The comparison chart 
uses a relative scale where minimum and maximum values are always shown at the same 
locations and other values are placed in between according to the scale created by the 
spread between minimum and maximum. 

Clicking on additional components will display additional parameter lists. These lists 
contain all parameters associated with a component, therefore there is overlap between 
connected components. The location of the mouse pointer determines where the list is 
displayed. This feature allows you to control which parts of the schematic will be 
obscured. 


Clicking on additional list items, i.e. parameter names, replaces the comparison chart with 
the newly selected parameter data. 

To remove any list or chart completely you have to click the button "Hide Data" which 
erases ALL lists and the comparison chart if displayed. 

The button "Show Labels" displays labels which identify the major SSME components in 
the schematic. The labels can be removed by clicking "Hide Labels". 

The button "Diagnosis" leaves the anomaly inspection step and starts diagnosis; it is 
equivalent to the "Diagnosis" button in the previous screen (the anomaly list screen). 

The button "Modify Anomaly List" takes you back to the previous screen (the anomaly list 
screen) where you can add and delete anomalies based on the information gathered from 
inspecting the data values. 
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3.2.3.6 Diagnosis Control Screen 

Here you are able to inspect and modify the diagnostic strategy. Currently, you have to 
accept the initial suggestion because only the qualitative reasoning mechanism is 
implemented. 

The EXPLAIN button does nothing yet. 

The EVALUATION STRATEGY button takes you to a screen which is a model of how we 
will let the user modify numeric strategy parameters which tune system performance. 
Currently you may change the displayed values but they are not used. They should be 
replaced by more useful parameters, see the section on tuning system performance. 

The Continue button starts the diagnostic reasoning process. After a short time the "First 
Component" screen will appear. 

3.2.3.7 First Component Screen 

WARNING: The features described below may or may not be implemented in the current 
version of EDIS! 

The performance, i.e. the time it takes to produce a diagnosis and the order in which 
competing diagnoses are produced, of EDIS is quite sensitive to the order in which 
component behavior is analyzed (and to the strategy parameters). Currently, the strategic 
parameters are set so that EDIS attempts to find a faulty component as soon as possible. 
If, for example, normal and faulty behavior for the first component are possible choices, 
then EDIS will assume a fault unless the faults are too unlikely. EDIS will then verify the 
consistency of this assumption with all other measured data and reject it if necessary, but 
a bad first choice leads to a lot of wasted time. Also, a component which has fewer 
unknown parameters will lead to fewer behavior choices which accelerates further 
processing. 

Therefore, EDIS a) attempts to make a good guess as to where to start and b) allows the 
user to change the selection. 

For this reason provisions were made in the system architecture to be able to add 
additional knowledge sources which may optimize the search process, such as heuristic 
rules. This is not currently implemented, however. 

The component EDIS suggests is selected based only on the number of known parameter 
values associated with it. A pipe, for example, is currently modeled using six parameters. 
If EDIS knows the values of two of these six parameters it will prefer this pipe to another 
component where maybe two of eight parameters are known. As you can see, EDIS does 
not take component fault likelihood into account and a bad first guess is possible. If you 
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suspect this, change the initial selection by clicking on the CHANGE button; if you want 
to know more about the component and its associated parameters click on INSPECT; and 
if you agree click on ACCEPT. 

If you choose INSPECT you will see the number of known and unknown parameters and 
the qualitative values of the parameters associated with the component. 

If you choose CHANGE you may choose a different component from a scrollable list of 
components. For this new component you may again select INSPECT, CHANGE or 
ACCEPT. 

If you choose ACCEPT you will be asked whether you want to supply additional qualitative 
data and/or if you want to suggest a fault hypothesis for this component. A good guess 
on your part can speed up diagnosis. A bad guess will slow down EDIS but will not 
eliminate the correct diagnosis even if it contradicts your guesses. Your answer will only 
influence the heuristic evaluation functions so that EDIS’ guesses will conform to yours 
initially. If you advance a fault hypothesis EDIS will first test whether your hypothesis is 
compatible with all measured data without having to assume additional faults. Note that 
the above described behavior of EDIS depends on the values of the strategic parameters. 

After you choose ACCEPT EDIS will start processing. This can take a long time depending 

on the number of unknown parameters, e.g. ca. five minutes for four unknown parameters 
of a pipe. 


When EDIS has finished working an a component it will show a status screen. 
3.2.3.8 Diagnosis Status Screen 


WARNING: The features described below may or may not be implemented in the current 
version of EDIS! 

The status screen indicates whether a complete diagnosis has been found. If so, its quality 
and details are available for user inspection. If not, the current state and progress made are 
available. 

3.2.3.9 EXIT 

When you are done select EXIT from the EXIT menu to leave EDIS. 
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4. DEVELOPER GUIDE 


4.1 System Architecture 

The EDIS system consists of two main parts, a knowledge-based reasoning system written 
in NEXPERT and a user interface written in TOOLBOOK. Both tools use Microsoft 
Windows and communicate through dynamic link libraries (DLLs). The TOOLBOOK code 
contains instructions to load and initialize the NEXPERT session. TOOLBOOK code 
requests expert system processing by suggesting data and volunteering hypotheses (the 
NEXPERT kind). NEXPERT requests interface support by executing calls to routines which 
are handled by TOOLBOOK, i.e. for which TOOLBOOK has installed a handler script via a 
DLL call. 

TOOLBOOK code reads the data files while NEXPERT code reads all other files, e.g. 
2-sigma limit data, component and parameter configuration, etc. All relevant data are 
maintained in NEXPERT, changes made by a user interacting with the interface are 
immediately propagated to NEXPERT. 


4.2 Installation 

Itostall TOOLBOOK and NEXPERT first. During NEXPERT installation request that the 
TOOLBOOK bridge and the Windows DLL be installed. The *.DLL files will be put in the 
NEXPERT\NXPTBK subdirectory. All EDIS code must reside in this directory! 


EDIS code consists of the files 


EDIS.TBK 

KB111B.TKB 

KB111C.TKB 

PLANNER. TKB 

QUALIT.TKB 

CONSTRN.TKB 


[TOOLBOOK code] 

[NEXPERT code: configuration 
and 

anomaly detection; 
qualitative 
diagnosis] 


In addition, a set of configuration files must reside in this directory, see below (we may 
change this so that the configuration files reside in a subdirectory called CONFIG). 

NOTE: You must have the NEXPERT authorization module plugged into your PC before 
executing EDIS. 
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NOTE: There may be a problem when you run a large application, i.e. one where too many 
dynamic objects are created. As far as NEXPERT by itself is concerned (without 
TOOLBOOK) I made the following observations: If you are not developing you may want 
to replace the NEXPERT.EXE file by the file BIN\STDALONE.EXE which does not contain 
support for editing but can handle large problems. The development version tends to crash 
when too many dynamic objects are being created. There is even a version supposedly for 
large applications called STDALONL.EXE but I could not get it to work properly. 

Neuron Data has sent me a pre-release large development version, but said that there may 
also be a problem with the DLL version (to be used by TOOLBOOK). There will be a large 
DLL version available which you maybe will have to obtain when you are running EDIS 
on the full SSME configuration. 

4.3 EDIS Configuration 

4.3.1 Configuration files 

You must provide files which describe the physical SSME configuration, i.e. components 
and interconnections, which parameters are measured by sensors, and limit data. You 
should provide a file which lists probabilities of common faults. See Appendix F for 
examples. 

The physical configuration is defined by a set of files, one for each component type, i.e. 
NEXPERT class. For example, there are files PUMP, PIPE, VALVE, etc. All the component 
classes are subclasses of class "STATIC COMPONENT’ in NEXPERT. Some file names do 
not directly correspond to class names, e.g. file "gturbine" contains the definition of 
GAS TURBINE objects. Check the rule with hypothesis "CONFIGURE_COMPONENTS" to 
see how the files are loaded and the components are defined. A configuration file defines 
(among other things) the component name, its connections, and its associated parameters 
(only those which are measured have to be defined). The connections are specified by 
entering the name of the connected component in the appropriate slot. The associated 
parameters are specified by name which must correspond to a name in the parameter 
configuration file. For each measured parameter you must identify which "generic" 
parameter it corresponds to. For example, the LPFP_DS_PR is the output pressure, or 
"pout" for short, of the low pressure fuel pump. The name used must correspond to the 
name of a slot in the behavior class for this component. (For each component class there 
exists a corresponding behavior class, see the section on changing the configuration). 
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The component types currently supported are 


Component Class FILE Notes 


PUMP 

PUMP 

PIPE 

PIPE 

VALVE 

VALVE 

GAS TURBINE 

GTURBINE 

TANK 

TANK 

PRE BURNER 

PBURNER 

COOLING 

COOLING 

TWO SPLIT 

TWOSPUT 

TWO_JOIN 

TWOJOIN 

THREESPLIT 

TRISPLIT 


e.g. LPFP, HPFP 
1 -input, 1 -output 
e.g. MFV, FPV 
e.g. HPFT 

No behavior definition 
e.g. FPB 

e.g. MCC_COOLING 
pipe split: 1-input, 2-output 
pipe join: 2-input, 1 -output 
pipe split: 1 -input, 3-output 


One additional file deals with physical configuration. The file TERMINAL lists the names 
of those components which are not of interest during diagnosis. For example, the fuel tank 
has to be defined because it is connected to the LPFP but EDIS does not reason about faults 
of the tank. The tank is therefore listed in the TERMINAL file. The main reason for this 
file is to isolate the configuration from supporting and bounding components. However 
you may list any component in this file and it will be ignored by the reasoning process! 
This is currently the only way to limit the reasoning process to a particular portion of the 
SSME as configured. 

Measured parameters are defined in file PARAM1.NXP. For each parameter an object of 
class MEASURED_P ARAMETER is created in NEXPERT. The most important entry 
(NEXPERT slot) is the SENSOR_PID_NUMBER which allows EDIS to transfer data from 
TOOLBOOK to NEXPERT without enforcing use of identical parameter names. TOOLBOOK 
contains a page for every measured parameter identified by the PID number. Test and 
comparison data are read into fields on this page at the beginning of a session, as described 
in the user guide. TOOLBOOK relies on the order of parameter values in the data files 
when assigning them to PIDs. 

The 2-sigma limit data are stored in file SIGMA. NXP. It has to be created from a data base 
file in SYMPHONY format. The SYMPHONY file should be called SIGMA5.WRI so that 
EDIS can create SIGMA.NXP from it automatically. The symphony file must list the data 
in columnar format, i.e. transposed from the original format. The data must be explicit, 
not defined as formulas. The header row and data records must be defined as a range 
named TRY. The range should only include the 104% MAX FUEL data recods. 

The file named FAULTS lists common faults and their probabilities. You specify a 
component type, e.g. "pipe", a fault mode, e.g. ’leak", and a probability, e.g. "0.1". The 
probability is used to rank competing fault hypotheses. An unknown fault, i.e. one which 
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has no name, has probability 0.01. The rating and ranking method is described in more 
detail in the section on performance tuning. 

4.4 Changing the Configuration 

4.4.1 Simple Configuration Changes 

Only the component configuration files have to be modified in order to change the physical 
configuration of the SSME as long as no new component types are introduced. In fact, 
EDIS will work for any liquid fuel rocket engine or any high-pressure fluid system 
consisting of pipes, pumps, valves, etc. Neither the component types nor the behavior 
models are specific to the SSME. Just make sure the component configuration files are 
complete and consistent. 

A configuration change invalidates the schematic drawing, however. It will have to be 
updated by hand using TOOLBOOK’S author mode. Whether you use line drawings, as was 
done for the SSME, or other means to create the drawing, it is important that you define 
objects, e.g. groups of lines, which correspond to each component and give each group the 
name of the component as defined in NEXPERT. If this is done EDIS will be able to access 

and display information on the parameters associated with the component as described 
above. 

4.4.2 Sensor Changes 

Oianges have to be made in both TOOLBOOK and NEXPERT if additional sensors are 
implemented. For NEXPERT, the configuration file PARAM1.NXP and the files which 
define the components associated with the newly measured parameter have to be updated. 
For TOOLBOOK, a page has to be added for each new parameter and the algorithm which 
reads the data from the ASCII file has to be modified. We regret this inconvenience but 
the data files do not contain any information on which parameters are contained. Also be 
sure to update the algorithms for both current and comparison test data. (This should be 
cleaned up.) The algorithm is in the book script in the handler "loadTestData". 

4.4.3 Focusing on Part of the SSME 

In order to focus on only part of the SSME, i.e. a subset of the components of the SSME, 

the fine TERMINAL can be modified to include all those components which should be 
neglected. 

4.4.4 Adding Fault Types 

Fault types are easily added in the FAULTS file. Follow the style of the entries already 
there. The probability should probably be around 0.1 so that it is higher than that of an 
unknown fault (0.01) and lower than 1.0. Also, adjust all fault probabilities in this file so 
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that they reflect your judgement and experience about the relative likelihoods of faults of 
the SSME. The absolute values are not too important but you should implement a rank 

ordering among faults so that the more likely ones have higher probabilities then the less 
likely ones. 

4.4.5 Modifying the Graphical Data Presentation 

You may want to to modify the graphical presentation of data on the schematic drawing 
screen when additional limit data become available. The script for handler "showGraph" 
on page "schdiag" should be clear enough to allow you to adapt the algorithm. 

4.4.6 Adding A Component Type 

Knowledge about new component types has to be added to NEXPERT when configuration 
changes call for components which have not yet been described to EDIS. This is the most 
difficult change in configuration and requires special care. In general, try to reuse as much 
of the code present and use it as a template when additions cannot be avoided. Also, be 
careful to add new classes and rules to the appropriate knowledge bases so that they are 
loaded in correct sequence. A mistake here could cause NEXPERT to display warning 
messages which will lock up your Windows system. Throughout we will pretend to add 
the type VALVE to the system to illustrate the procedure. 

Choose a name for the component type, e.g. VALVE. Identify its connections to other 
components, e.g. medium input and output, and position control input. Identify its internal 
and external parameters. Here we may note that the new component is similar to an 
already existing component. For example, the valve is structurally similar to a pipe since 
both have a single medium input and output. Its behavior is, in part, a subset of the 
behavior of a pump, because in both cases we may choose to ignore the possibility of leaks 
and a pressure change takes place. Structure and behavior are implemented separately. 

4.4.6. 1 Structure Definition 

In KB111B.TKB create a class with the name chosen for the new component type, and 
make it a subclass of an appropriate parent class. Display the class hierarchy starting at 
STATIC_COMPONENT to identify a good place. You only need to watch for connectivity 
similarities. For example, we make VALVE a subclass of THERMO_COMPONENT and 
inherit the ASSOCIATE_PARAMETERS, GENERICPARAMETERS, MEDIUM 
MEDIUM_INPUT, MEDIUM_OUPUT, and NAME slots. We now add a slot for the 
connection to the controller, e.g. CONTROLLED_BY. The last four slots define which 
(generic) parameters in the neighboring components are equivalent to the interface 
parameters of a particular valve. Normally, the output pressure "pout" would be equivalent 
to the input pressure of the next component which might be called "pin" and you may think 
that this could be assumed automatically. However, some components have two inputs 
such as pipe joins and prebumers, and use "pin" and "pinB" or "pinOX" as parameter 
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names. We recommend that you define a meta-slot for each of these slots which initializes 
it to the most common name, e.g. "pout” here. If you do this the configuration files need 
only specify deviations from this normal assumption. It is convenient to use the names of 
the generic parameters as defined in the behavior class in these slots, e.g. pin, pout, Vin, 
Vout, commanded_position. These names are the names of slots in the behavior class. 

(©CLASS = VALVE 

(©PROPERTIES = 

ASSOCIATE_PARAMETERS 

CONTROLLEDBY 

GENERIC_PARAMETERS 

MEDIUM 

MEDIUMJNPUT 

MEDIUM_OUTPUT 

NAME 

parameter_coupled_to_pin 

parameter_coupled_to_pout 

parameter_coupled_to_Vin 

parameter_coupled_to_Vout 

parameter_coupled_to_commanded_position 

) 


4.4.6.2 Behavior Definition 


Behavior defimtion is more difficult. In QUALIT.TKB create a behavior class named <new 
component >_BEHAVIOR, e.g. VALVE_BEHAVIOR, and make it a subclass of 
COMPONENT BEHAVIOR. Now you have to modify some slots which apply to all 
behaviors, add component-specific slots, define meta-slot procedures for some of these 
slots, and create rules which manipulate slot values. 


(@CLASS= VALVEBEHAVIOR 
(©PROPERTIES = 

add_fault_type 

commanded_position 

comp_name 

controlslot 

exchange_hypo 

fault_hypo 

fault_type 

faulty 

localquality 
neighbors 
next slot 
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normaI_quality 

num_known_params 

num_nnknown_params 

open_parameters 

p_diff 

pin 

position 

pout 

temporary 

Vbar 

Vin 

Vout 

) 

) 


Behavior should be defined in terms of constraints on parameter values derived from 
energy and mass conservation equations. The derivation of constraints is described in 
chapter 2. For implementation, fundamental constraints lead to rules which detect 
component faults. Normative constraints and auxiliary equations together are implemented 
as rules which determine whether a given assignment of parameter values is physically and 
mathematically possible. Rules based on mathematical constraints relate derived to 
measured parameters, e.g. pressure difference to input and output pressures. 

4.4.6.2.1 Additional Slots 

In this example we added slots for input and output pressure and temperature (pin, pout, 
Vin, Vout), actual and commanded valve position (position, commanded_position), and a 
slot which lists the neighbors of the component. The "neighbors" slot should actually 
reside m the structure definition. 

The parameter slots, e.g. pin, pout, require an "Order of Sources" and an "IF Changed" 
meta-slot method. The "Order of Sources" slot is the same for all parameters, copy it from 
another behavior class. The "If Changed" slot is used to either set other parameters and/or 
more importantly, to test the possibility of the behavior specified against the behavior 
constraints for this component type. In some cases, the parameter may have any value and 
does not require constraint testing. For example, we neglect the possibility of leaks in a 
pump and assume that input, output, and average fluid velocity (or flow) in the pump are 
identical. If one of these three parameters changes so must the other two. The "If 
Changed slot enforces this. Look at the Vin and Vout parameters of PUMP BEHAVIOR 
for examples. We suggest to make the same assumption for the VALVE. Any leak will thus 
be attributed to the pipes leading to and away from a valve. If the parameter is subject 
to constraint testing, however, the "If Changed" slot will suggest one or several hypotheses 
which trigger constraint rules. These rules test if, after enough parameter values have been 
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determined, a behavior constraint can be shown to be violated. If so, the particular 
behavior is be discarded. You may want to wait until you have defined the constraint rules 
before you complete such a meta-slot. These constraint rules identify the impossible 
behaviors and mark them for later deletion. Look at the "pin" parameter of 
PUMP BEHAVIOR for an example. Both cases discussed above may apply to a parameter, 
e.g. the Vbar parameter of PUMP_BEHAVIOR. It was chosen at random (from Vin, Vout’ 
Vbar which are all the same) to represent fluid velocity in the constraints. Therefore it has 

both statements which update Vin and Vout as well as statements which trigger constraint 
rules. 

Every component needs a "neighbors" slot with associated "Order of Sources" meta-slot 
which defines how to find the neighboring, i.e. connected, components. Part of this 
procedure is accomplished by a meta-slot in class TWO_PORT_BEHAVIOR. If the new 
component has fluid input and output like PIPE or VALVE you can make it a subclass of 
TWO_PORT_BEHAVIOR and you only have to add neighboring components which are 
attached to additional interfaces. A VALVE has an additional neighbor via the 
CONTROLLED_BY slot and we add to the meta-slot definition. Even if only fluid input and 
output are present, the meta-slot method has to be completed for the new component, as 
can be seen in class PIPE BEHAVIOR. 

4A.6.2.2 New Slot Names 

Try to reuse existing names, such as Vin, Vout, etc. as much as possible to describe 
component parameters. If you have to define new names, such as "position" in our VALVE 
example, you have to add additional information. 

For each new parameter name define rule called "expand_behavior_<name>". It is best to 
copy this rule from an existing parameter, e.g. pin, and change the parameter name 
everywhere. Create a fill..." rule for the parameter. It is best to copy this rule from an 
existing parameter, e.g. pout (rule fill2), and change the parameter name everywhere. In 
the example, "position" and "commanded_position" are new parameters. Create pair of rules 
"OPEN_ < name > _t" and "OPEN_<name>_f which test whether the parameter has a value 
yet. Compare rules "OPEN_Vin_t" and "OPEN_Vin_f, for example. 


Finally, if the parameter is an interface parameter, you have to determine which parameter 
in any neighboring component it may made to be equivalent to. For example, Vout may 
be equivalent to Vin, but also VinB and VinOX. You have to check all existing 
components which my be connected to this interface. In the example 
"commanded_position" is a new interface parameter. Since the valve position input may 
only be connected to the engine controller its "commanded_position" parameter may only 
be equivalent to the "commanded_position" parameter of the engine controller. You need 
to create a x_data_<name>" rule for each equivalence. It is best to copy this rule from 
an existing parameter, e.g. rule x_data_Voutl, and change the parameter name everywhere. 
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In the example, we need a "x_data_commanded_position" rule. Also, for each pair of 
possible equivalent parameters you need a rule which checks for possible value conflicts. 
These rules are named "x_inc_<paraml >_<param2>". Again, copy and adapt an existing 
rule. 

This seems to be unnecessarily complicated but the extra code is necessary because 
NEXPERT does not allow indirect specification of slot names. 

4.4.6.2.3 Modified Slots 

The "Order of Sources" meta-slot method of slot "add_fault_type" triggers rules which 
identify particular fault modes of a component, e.g. leaks or obstructions in a pipe. These 
rules may or may not be present but should be provided if some fault behaviors are more 
common than others. Write rules which identify the fault behavior and add its probability 
to the FAULTS file. If you do not specify the meta-slot it will be inherited from 
COMPONENT_BEHAVIOR which covers the cases of leaks and obstructions in a conduit. 
An example rule is "leak_is_present_l". 

The "exchange_hypo" slot has to be initialized to a hypothesis which exchanges data values 
with the neighboring components. Compare slot PIPE_BEHAVIOR.exchange_hypo and 
hypothesis PIPE_X_DATA of rule "pipe_x_datal". These rules make sure that parameters 
at interfaces between components are shared. A valve shares data with three neighbors: 
the commanded_position with the controller in addition to pressures and velocities at the 
medium input and output. 

The "fault_hypo" slot has to be initialized to a hypothesis which determines whether the 
current behavior is faulty. At this point no specific fault mode has to be recognized. In 
general, there will be some cases which correspond to a known fault mode or behavior and 
some which are unknown or "strange", all of which have to be detected with these rules. 
Compare rule "pump_test_faultl". These rules follow from the fundamental constraints of 
the component. 

The "num_unknown_params" slot has to be initialized to the number of parameters 
associated with the component. Groups of parameters which are identical, such as Vin, 
Vout, and Vbar in the pump, count only once. 


The "open_parameters" slot needs an "Order of Sources" meta-slot method which executes 
a rule that determines which parameters have not received a value yet. Compare, for 
example, the slot PUMP.open_parameters and the rule leading to hypothesis 
"CHECK_OPEN_PARAMS_PUMP". All internal and external parameters must be tested, 
each with its own rule. Only one of a group of identical parameters has to be checked. 
The rules which test each parameter should already exist at this point. You may have 
added some in step 4.4.6.2.2 above. 
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4.4.6.3 Constraint Rules 


Most of the required rules have been discussed in enough detail in the previous sections. 
This section will add information about constraint rules. 

EDIS creates possible component behaviors by enumerating all possible values for each 
undetermined parameter. After enumeration physically or mathematically impossible 
behaviors are discarded. The rules which are triggered by the "If Changed" methods of the 
parameter slots in a component behavior object perform this elimination task. Therefore 
the left hand side of these rules matches to impossible value assignments. Sometimes it 
is not perfectly obvious if a behavior, i.e. or value assignment, is possible due to the 
uncertainty associated with qualitative values. For example, even if input and output 
pressure are considered normal, the pressure difference may still be considered high if the 
input and output pressures are just barely normal at opposite ends of the scale. The 
judgement depends on the somewhat arbitrary placement of the limits between normal 
high and low. Often, if we assume a consistent limit definition, some cases can be 
eliminated. In the above example, we may know that the pressure difference will be 
normal for all values of input and output pressure which are considered normal. This 
stricter assumption will eliminate more of the generated scenarios. Fewer behaviors mean 
faster execution. Our approach is to locate rules which are sure to eliminate only 
impossible cases in knowledge base QUALIT.TKB and rules which apply only under strict 
assumptions about choice of limits in file CONSTRN.TKB. Currently file CONSTRN.TKB 
is loaded automatically, but you may simply remove the load command. EDIS will then 
consider more cases which will, in general, slow down the system. On the other hand it 

m /rowr P L SS L lble that the additional strict rules eliminate the only reasonable description 
of SSME behavior, although we think that this is unlikely. 


Originally constraint rules were created for each component type individually For 
example, PUMP_TEST_POSSIBLE_PV eliminate behaviors which incorporate impossible 
combinations of labels assigned to parameters PV_Product, p-diff, and Vbar. The rule is 
derived from the constraint PV_Product "p" p-diff + Vbar. Note that the implementation 
makes use of three-place (and one four-place) constraints in contrast to the theoretical 
exposition in Chapter 2 which allows only two-place constraints. The above constraint was 
derived from the mathematical relationship which defines the derived parameter 
PV - P ^ duct as Ae Product of p-diff and Vbar. Since PV_Product increases with both p-diff 
and Vbar their relationship can be described by an additive constraint. The majority of 
relationships encountered can be represented by additive or subtractive constraints. 

Currentiy, we are adding generic methods, i.e. rules, for testing additive and subtractive 
constraints. The If-Changed method of each parameter slot involved in such a constraint 
copies the relevant parameter values into slots "X", "Y", and "Z" of object "GCO" (short for 
generic constraint object). Additive, i.e. X=Y+Z, and subtractive, i.e. X=Y-Z, constraints 
can be tested by suggesting hypotheses CONSTRAINT_ADD_POSSIBLE and 
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CONSTRAINT_SUB_POSSIBLE, respectively. Make sure that the behavior object being 
examined is linked to class TEMP_BEHAVIOR as these two rules assume that. If you do 
not want or cannot use these generic rules you have to provide explicit rules similar to the 
rules with hypothesis PUMP_TEST_POSSIBLE_PV discussed above. 


4.5 Tuning System Performance and Strategic Parameters 

The most significant tradeoff is made when you decide whether to load the knowledge-base 
CONSTRN.TKB or not. The decision to load it restricts the number of solutions EDIS will 
pursue, see above. All other performance tuning mechanisms change only the order in 
which alternatives are considered. This may still turn out to be significant because the 
execution time to enumerate all solutions is probably too long to consider finite. Solutions 
which would be generated "late" are thus never generated. 


Tuning may be required for selection of the first component to analyze, for selection of 
subsequent components to analyze, and for evaluation of partial solutions. 

The first component is selected based only on the ratio of known to unknown parameters 
but the choice may be overridden by the user, see section 3.2.3.7. 


Given a partial solution the next component to be analyzed is again chosen based on the 
ratio of known to unknown parameters, except that components which are connected to 
the last analyzed component are given precedence. This generates a less "jumpy" flow of 
analysis. 

Partial solutions, i.e. scenarios, are evaluated using a number of contributing factors which 
are rated individually. A composite numeric score is accumulated and the best partial 
solution is chosen for further expansion until all components have been analyzed. 
Contributing factors are the number of faulty components in the partial scenario and the 
score or probability of each fault. The scores for the number of faults are defined in order 
m slot quality" of object SCENARIO_EVALUATION_OBJECT. The values are 1 0 for no 
fault, 90.0 for one fault, 8.0 for two faults, and 1.0 for three or more simultaneous faults. 
For each fault, its probability is sought. If it was defined in file FAULTS the probability 
given there is used, if not 0.01 is used. These values are multiplied to the partial score. 
Frnalty, the score of each partial scenario is increased by the number of components is has 
already analyzed. This eliminates overly frequent shifts of the focus of attention. 

Fot example, the score of a partial scenario with one fault, a pipe leak, is 90.0 times 0.1 
which is the probability measure defined for pipe leaks in the current FAULTS file. The 
total score is thus 9.0. A further fault would reduce the score to near 1.0. In fact, a partial 
scenario with no faults is considered to be about as likely as one with two faults. This is 
basically sound, but since the scoring does not (or hardly) depend on how far the 
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reasoning has progressed, a single fault will be assumed at the first component analyzed, 
unless there is no known fault behavior which fits the available data. In the latter case the 
fault score of 0.01 will make the combined score 0.9 which is less than 1.0 for the no fault 
case. You may want to experiment and modify these numbers. 
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5. STATE OF DEVELOPMENT 

5.1 Hardware and Sofware Setup 

EDIS runs on 80386 based personal computers with color VGA display. Between ten and 
twenty megabytes of hard disk space are required depending on which portions of the tools 
are loaded. Four megabytes of RAM, a math coprocessor, and a mouse are recommended. 

EDIS uses the software tools NEXPERT, an expert system shell, and TOOLBOOK, a 
graphical user interface design tool. Both software tools require Microsoft Vfindows 3.0. 
To run EDIS only runtime licenses are needed, but the experimental nature of EDIS makes 
development licenses desirable. 


5.2 Interface 

A large portion of the user interface has been implemented, especially the parts which deal 
with setup, configuration, initialization, and anomaly detection. A dynamic image of the 
SSME schematic is available which shows parameter values relative to limits. The interface 
to the qualitative diagnosis mechanism is only partially available. The explanation facility 
has not been coded yet. 

5.3 Knowledge Base 

The qualitative reasoning mechanism has been implemented and a limited number of 
component types are supported. No other types of reasoning are supported yet. 

Currently structure models of component types PIPE, PUMP, COOLING, GAS TURBINE 
VALVE, TWO SPLIT, THREE_SPLIT, TWO_JOIN, PRE_BURNER, and TANK are 
implemented. Complete behavior models exist for PIPE, PUMP, COOLING, TWO SPLIT 
THREE SPLIT, and TWO JOIN. In all cases only pressures and temperatures are 
considered, temperatures and heat transfer is ignored (which makes COOLING just like 

DrDC'l J 
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6. SAMPLE CASES 


Two simple sample cases will be presented in this chapter. Both are based on a small 
configuration of pipes which is not related to the SSME but is simple enough to explain the 
reasoning process performed by EDIS. The configuration consists of a pipe FI 01 which 
feeds into a pipe-split M102 which, in turn, feeds into pipes F102 and F103. Note that the 
configuration files have to define additional components which serve to terminate the input 
and outputs but will not be analyzed. 

In the first case three measurements are available: input pressure and flow at pipe FI 01 
and input velocity at pipe F102. Normally, a measurement at the input of F102 would be 
shared with the output of M102 which is connected to the input of F102. In this example 
we omit this parameter sharing in order to demonstrate a special case of value propagation. 
All measured values are NORMAL. 

In the second case an additional measurement is available: the output pressure at pipe 
F103. It is also NORMAL. 

The examples will demonstrate how EDIS analyzes a configuration component by 
component, assures consistency between components, and backtracks, if necessary, when 
assumptions become unlikely when new measurements are encountered. The second case 
demonstrates the backtracking mechanism in particular. The examples will demonstrate 
how EDIS, using its default strategy, tries to find a single fault as soon as possible. You 
can see how this may lead to inefficiencies when the initial fault assumption is incorrect. 
Remember that this behavior depends on the strategy parameters described in a previous 
chapter and can be easily modified. Also, the user is given the opportunity to influence 
behavior and fault assumptions. Here we show how operates without user intervention. 
It should be clear now that the initial hypothesis generated by EDIS will contain a fault 
even though all measured parameter values are normal. 

6.1 Case 1: No Backtracking 

EDIS selects a component to analyze. At first the only criterion is derived from the ratio 
of the number of known parameters versus the number of unknown parameters. A pipe 
has 6 parameters and a pipe-split has 4. We know two of the six parameters of F101, 
therefore it will be analyzed first. We assume that the pressure is constant throughout the 
pipe-split and use the generic parameter name "pin" for it. 

All possible behaviors of pipe F101 are created. Given the two measurements nine 
behaviors survive constraint testing. Some of them describe normal behavior but most 
imply a fault of the pipe. In this version of EDIS two faults are defined for a pipe: an 
obstruction with merit 0.2 and a leak with merit 0.1, which indicates that we believe that 
an obstruction is more likely than a leak. A leak is identified by a drop in flow from input 
to output while an obstruction causes an undue pressure drop. 
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Each behavior of pipe FI 01 generates a new partial scenario. Each scenario is rated based 
on the number of faults it predicts, the merit of each behavior it contains, and how many 
components it already describes. The basic ratings for no, one, two, and three or more 
faults are 1.0, 90.0, 8.0, and 1.0 respectively. The appropriate base rating is then 
multiplied by the rating of each behavior contained in the scenario. Normal behavior is 
rated 1.0 while faulty behavior is rated by the figure of merit associated with the fault. 
An unidentified fault has merit 0.01 and will therefore not be considered until all other 
options have failed. 

EDIS selects the most promising partial scenario, i.e. the one with the highest rating, to 
expand. This is because EDIS actually performs best-first search in the space of all SSME 
behaviors. In this case the highest rated scenario is Scenario-4 which assumes an 
obstruction in pipe FI 01. A consequence of this fault assumption is that the output 
pressure of FI 01 will be assumed to be LOW and this value is propagated to pipe-split 
M102, together with the output flow which is NORMAL in this case. 

Next, all possible behaviors of Ml 02 are generated. Since two of its four parameters were 
determined via propagation only three or four behaviors are possible. Propagation of the 
output flow to F102 may lead to a conflict with the measured value at the input of F102. 
Scenarios which lead to such a conflict are discarded. In our case only a single behavior 
of Ml 02 is consistent with the interface conditions. It predicts normal flows and low 
pressure. 

Next, pipe FI 03 is analyzed. This time 15 behaviors are possible and EDIS chooses a 
normal, i.e. non-faulty, behavior since the scenario ratings for the two-fault cases are 
obviously worse. The chosen behavior predicts normal flows and pressure drop but low 
input and output pressures. 

Finally, pipe FI 02 is analyzed. EDIS chooses the same behavior as for FI 03. Now the 
scenario is complete. It contains a complete account of SSME behavior in terms of all 
relevant parameters and the fault hypothesis that pipe F101 is obstructed. It is clear that 
other explanations of the measurements are possible because three measurements are far 
too few to lead to a unique answer. The search strategy and fault likelihoods supplied to 
EDIS led to this particular answer. EDIS could, if requested, generate further answers if 
we force it to backtrack. 

6.2 Case 2: Backtracking 

The second case is identical to the first except that a measurement for the output pressure 
of pipe FI 03 is added. The value supplied is NORMAL. Processing begins the same way 
and the first two steps are identical! EDIS considers F101 first and chooses a behavior 
which implies a pipe obstruction. Note that the output pressure of FI 01 is assumed to be 
LOW according to this fault hypothesis. Analysis of pipe-split Ml 02, too, leads to the same 
result as before. 
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When EDIS reaches pipe FI 03, however, it cannot find a normal behavior for FI 03 given 
the propagated input values and the measured output pressure. It has to assume a second 
fault: a leak, for example. This drops the rating of the resulting scenarios below the rating 
of earlier scenarios which predict only a single fault. The bonus for covering more 
components is less than the penalty for a two-fault hypothesis. EDIS therefore abandons 
these scenarios in favor of a scenario which has the highest rating at this point. In this 
case it is a scenario with only F101 analyzed where F101 is again assumed to be faulty, 
but the fault is supposed to be a leak instead of an obstruction. There are, however, a 
number of behaviors possible given that the pipe has a leak. EDIS chooses one at random 
since they all have the same rating. It turns out that again no single fault hypothesis can 
be supported by this choice of behavior for pipe FI 01 and EDIS has to put aside its 
assumption in favor of a different one. 

Another behavior for FI 01 is now chosen, again with a leak fault, and it fails also. Finally, 
a forth behavior of pipe FI 01 is selected which leads to a complete hypothesis with only 
one fault. Interestingly, the fault proposed is again a leak in pipe F101, supported by a 
different behavior of FI 01 given the leak. This behavior predicts LOW output flow (this 
is the characteristic of a leak) and also LOW output pressure. The pipe-split behavior 
chosen assumes that the input flow is divided so that the output flow into FI 03 is LOW 
but the output flow into FI 02 is (maybe just barely) NORMAL. The low flow through 
FI 03 then creates a reduced pressure drop in pipe FI 03 which allows for a NORMAL 
output pressure reading even though the input pressure was LOW. FI 02 sees LOW input 
pressure and NORMAL input flow and EDIS assumes that its output pressure and flow are 
LOW and NORMAL, respectively. 

The resulting scenario is considered optimal by EDIS and is offered as a valid diagnosis. 
Note, however, that with such few measurements several other answers would have been 
possible. Obviously, EDIS could have derived that there is no fault in the system since all 
measurements are NORMAL. Or, the output flow from the pipe-split into pipe FI 02 could 
have been assumed to be LOW just as for pipe FI 03. Then, the behavior of FI 02 would 
have been identical to that of pipe FI 03. A measurement of the output pressure of FI 02 
could distinguish between these two cases. Without additional data the choice of answers 
(actually, the choice of the order in which the answers are produced by EDIS) depends on 
the strategy parameters. 
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APPENDIX A 


LISTING OF EDIS INTERFACE (TOOLBOOK) CODE 
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LISTING OF EDIS DIAGNOSIS (NEXPERT) CODE 



APPENDIX C 


PARAMETERS USED BY EDIS 
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description 

TIME IN TEST THE DATA VALUES WERE TAKEN (COLUMN I IN 
SIGMA. WR1 FILE) 

MOCPCHbH=HENCE 

MOCPC 

LPFP DS PR 

LPFPDSTMP 

LPFPSPED 

HPFPDSPR 

MCCCLNTDS PR 

MCC CLNTDSTMP 

HPFTDSTMPA 

HPFT DS TMP B 

FPBPC 

HPFP SPED 

HPFP CLNT LNR PR 

MCC FUEL INJECTOR PR 

LPOPDSPR 

LPOPSPKD 

HPOPDSPR 

LOX DOME TMP 

PBPDSPR 

PBP DS TMP 

HPOTDSTMPA 

HPOTDSTMPB 

BK3 FUEL INLET TMP 

BIG FUB. INLET PR 

ENG OX INLET TMP 

BXBOXNLETPR 

FUELFLOW 

HPFPDSTVP 

HPFP BAL CAV PR 

HPFP COOLANT UNER TMP 

WFP DRAIN PR 

HPFP DRAIN TMP 

LPFT INLET PR 

FUB- PRESSURANT INTERFACE PR 
FUEL PRESSURANT INTERFACE TMP 
OPBPC 

FPOVPOSmON 

HPFPSPffl) 

LPFP SPEED 
HPOP BAL CAV PR A 
HPOP BALCAV PR B 

mccloxwjectorttup 

MCCLOXNJECTORPR 

POGOPR&CHARGEPR 

WAT EXCHANGE DS PR 

HEAT EXCHANGER NTERFACE PR 

HEAT EXCHANGER NTERFACE TMP 

OPOV POSTON 

LPOP S P SD 

hpopsphd 
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\MCC_COOL I NG . NAME\«"MCC_COOL IMG" 

\MCC_COOL I NG . MED 1 UMJXITPUT \*"F 1 09" 

\MCC_COOL I NG . HEO I UM~I NPUT \="M1 02" 

\MCC COOL IMG. MED IUM\>" FUEL " 

\MCC_COOL IMG. ASSOC I ATE_PARAMETERS\*"MCC CLNT DS PR" 
\HCC_COOL I NG . GENER I C_PARAMETERS\»"pout" _ 
\NOZZLE_COOL I NG.NAME\»"NOZZLE_COOL IMG" 

\NOZZLE_COOL IMG. MED I UM_0UTPUT\*"M201 " 

\NOZZLE_COOL IMG. MED IUM_I NPUT \»“M1 02" 

\NOZZLE_COOL I NG . MED IUH\«" FUEL" 

\NOZZLE_COOLING.ASSOCIATE_PARAMETERS\*"Notknown» 

********** 
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\FUEL_FLOU_COMTROILER.NAME\*"FUEL_FIOU_CONTROUER'' 

\FUEL_FLOU_CONTROtlER.COHTROlS\* M FPOV""" 

\FUEl_FLOW_CONTROLLER.HEASURES_AT\* M F101" 

\FUEL_FLOU_COWTROLLER.ASSOCIATE_PARAHETERS\="FUEL_FLOW,FPOV_POSITIOII" 
\FUEL_FLOU_CORTROLlER . GENER I C_PARAMETERS\="Vi n, commended _posi t i on" 
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\HPFP_CLNr_LMR_p R .sou RCEX= „ SYSTEMII 

\ HP FP'CLN T~LN R - p R ' SENSOR "pm X *" HP F TP - CL T _LNR_PR_ 1 04MF" 

- J.NRPR. SENSOR P id NUMBER\*"53» 

- L NT_LNR_PR .MEASUREMENT \«“S INGLE 11 

NHD«~r LNT - LNR - PR ’ GENER,C - NAME '* ,,p CLT" 

ss 

SrS^SKr - 1 * 1 

\MCC_FUEL_I M JEC T0R _p R . GENER , c N AME\«"P p 

vl^os^ n ^^x:«s;ss- a7e - c ^ 1 

^:SSOTSKa«-- 

UPOP_OS_PR.MAME\«»LPOP_DS PR" 

\LP0P_DS_PR . MEASUREMENT \"“S I NGLE" 

,\ L !?- 0S - PR • GEMER 1 c _NAME\.«P out P IN" 

, -^- PR ' ASSOCIATE _ c 0MPONENT\*"O201 HPOP" 
\HPOP_OS_PR.SOURCE\""SrSTEM« ' 

\HPOP_OS_PR. SIGMA NAME\«"HP0P DS PR IIUhcn 
\HPOP_OS_PR.NAME\"«HPOP OS PR" 

\HPOP_DS_PR.MEASUREMENT\*"SINGLE" 

\HPOP_DS_PR . GENER I C_NAME\«"P OUT P i N " 

Lr^- AS ^ 1AT£ - C ^ ERT N : - p OP,02 W « 

\LOX_OOHE_TMP . SOURCE \»"SYSTEM" 

\LOX_OOME_TMP. SIGMA NAME\««OX DOME T 104mp» 

\L0X_OOME_TMP . NAME\a"LOX DOME TMP" 

\LQX_DOME_TMP . measurement\z«s7ngle n 

\LOX_OOME_TMP . GENER I C_NAME\«"MCC" 

? THP ' ASS<X 1 A ^ E - C0KP «' E NT\.«MCC» 

\P8P_DS_PR . SOUR CE\""SY STEM" 

,S 1 OMA^NAME \*"PBP OS PR 104MF" 
\PBP_DS_PR.SENSOR_PI0 NUHBER\«»59" 
\PBP_0S_PR.NAME\-«P8P~0S PR" 

\PBP_DS_PR . MEASUREMENT \>"S INGLE" 

\PBP_0S_PR . GENER I C_NAME\*"P IN" 

^ddd""^ - ^ * ASSOC I AT E C0MP0NENT\""0205 " 

\PBP_0S_TMP . SOURCE\>"SYSTEM" 

^-° S -™ P ' SI “ A - NAME \- p fl p os T 104MF" 

\ eao _ ftf“™ P ‘ SEHSOR - P 1 0_W*«ER\»S94« 

\PBP_OS_TMP.NAME\b"PBP os TMP" 

\PBP_DS_TMP . MEASUREMENT \b"S INGLE" 

\PBP_0S_TMP. GENERIC NAME\»"T IN" 

Xp!^ W -* SWlAfE - C ^«T\""0205« 

\ENG_FUEL_INLET TMP. SOUR CE\>"SYSTPMm 

pSsssr 

xENfi'^i 1-- 1 NLET - TMP •heasurement\«"$7ngle«~ 

\«r'cnc " MLET - TW> - GEWER « C_NAME\"«T I N« 

~ L - rN L ET _TMP.ASSOCIAfE_COMPONENT\«"LPFP" 
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\ENG_FUEL_INLET_PR.SOURCE\="SYSTEM" 
\ENG_FUEL_INLET_PR.SIGHA_NAME\s"ENG_FL_INJ>R_104MF» 
\ENG_FUE L_INLET_PR . SENSOR P I D_NUMBER\="821 " 
\ENG_FUEL_INLET_PR.NAME\»"ENG_FUEL_INLET_PR" 
\ENG_FUEL_INLET_PR.MEASUREMENT\«"SINGLE"~ 

\ENG_FUE L_ I NLET_PR . GENER I C_NAME\""P_IN" 
\ENG_FUEL_INLET_PR.ASSOC1ATE_COMPONENT\»"LPFP" 

\ENG_OX_I NLET_TMP . SOURCE\*"S YSTEM" 
\ENG_OX_INlET_TMP.SIGMA_NAME\»“ENG_OX_IN T_104MF" 
\ENG_OX_lNLET_THP. SENSOR PID NUMBER\*"1058" 
\ENG_OX_INLET_TNP.NAME\»“ENG~OX_INLET_TMP“ 
\ENG_OX_INLET_TMP.MEASUREHENT\«"SINGLE" 

\ENG_OX_ I N L ET_TMP . GENER l C_N AHE \« " T_ I N " 
\ENG_OX_INLET_TMP.ASSOClATE_CCMPONENT\="LPOP" 

\ENG_OX_ I NLET_PR . SOURCE V*"SYSTEM" 

\ENG_OX_INLET_PR . S I GMA_NAME\=»ENG_OXJN_PR _1 04MF" 
\ENG_OX_ I NLET_PR . SENSORP ID_NUMBER\s"858" 
\ENG_0X_1NLET_PR.NAME\«"ENG OX_INLET PR" 

\ENG_OX_I NLET_PR .MEASUREMENT'S I NGLE" 
\ENG_OX_INLET_PR . GENER I C_NAME\""P_ I N" 

\ENG_OX_ I NLET_PR . ASSOC I ATE_COMPONENT \*"L POP" 

\FUEl_F LOU . SOURCE\««SYSTEM" 

\ F UEL_FLOU.SIGMA_NAME\«"FL FLOU_104MF" 

\FUEL_FLOW . SENSORP ID_NUMBER\»"ToO" 
\FUEL_FLOU.NAME\««FUEL FLOW" 
\FUEL_FLOU.MEASUREMENT\*"SINGLE" 

\ FUEL_F LOU . GENER I C_NAME \««V_0UT , V IN" 
\FUEL_FL0U.ASS0CIATE_C0MPONENT\s"F101,HPFP" 
\HPFP_DS_TMP. SOURCE\*"SYSTEM" 
\HPFP_DS_TMP.SIGMA_NAME\a"HPFP OS T 104MF" 
\HPFP_DS_TMP . SENSOR_P I 0_HUHBER\»»659" 
\HPFP_DS_TMP.NAME\«"HPFP_DS THP" 

\HPFP_DS_TMP . MEASUREMENT \* M S INGLE" 

\HPFP _DS_TMP . GENER I C_NAME\««T_I N , T_OUT" 
\HPFP_DS_THP.ASSOCIATE_COMPONENT\*»F102 , HPFP" 
\HPFP_BAL_CAV_PR . SOURCE\«"SYSTEM" 

\HPFP_BAL_CAV_PR . SI GMA_NAME\*"HPFP_BAL_CAV PR 104MF" 
\HPFP_BAL_CAV_PR . SENSOR PID NUMBER\""457" ~ 
\HPFP_BAL_CAV_PR ,NAME\»"HPFP BAL_CAV_PR" 
\HPFP_BAL_CAV_PR . MEASUREMENT'S INGLE" 

\HPFP_BAL_CAV_PR . GENER I C_NAME\»"P_BAL " 

\HPFP_BAL_CAV_PR .ASSOCIATE COMPONENT\*"HPFP" 
\HPFP_COOLANT_L I NER_TMP . SOURCE V—SYSTEM" 
\HPFP_COOLANT_LINER_TMP.SlGMA_NANE\»"HPFP CL T 104MF" 
\HPFP_COOLANT_L I NERTMP . SENSOR_PID_NUKBER\* ,I 650" 
\HPFP_COOLANT_L I NER_TMP . NAME \*“HPFP COOLANT LINER TMP" 
\HPFP_COOLANT_L I NER TMP .MEASUREMENT\»"S I NGLE" 
\HPFP_COOLANT_L I NER_TMP . GENER I C_NAME \-"T_CLT" 
\HPFP_COOLANT_L I NER_TMP . ASSOCIATE COMPONENT\»"HPFP" 
\HPFP_0RA I N_PR . SOURCE\«"SYSTEM" 

\HPFP_ORAI N_PR .SI GMA_NAHE\""HPFP_DRN_PR 1 04MF" 
\HPFP_ORAIN_PR. SENSOR PID NUHBER\>"657"~ 

\HPFP_DRA I N_PR . NAME\a"HPFP DRAIN PR" 

\HPFP_DRA I N_PR . MEASUREMENT\*"S INGLE" 

\HPFP_DRAI N_PR . GENER I C_NAME\""P DRAIN" 

\HPFP_DRA 1 N_PR . ASSOC 1 ATE_COMPONENT\>"HPFP" 
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\HPFP_DRA I M_THP . SOURCE\=»SYSTEM» 

\HPFP_DRA I N_TMP . S I GMA_NAME\*"HPFP_DRN_T_1 04MF" 

\HPFP_0RA I N_TMP . SENSORP I D_NUMBER\*"658" 

\HPFP_DRA IN_TMP. NAMc\*“HPFP_DRA I NTMP" 

\HPFP_DRA I N_TMP . MEASUREMENT V> n S I MOLE" 

\HPFP_ORAIN_TMP . GENER I C_NAME\«"T_DRA I N" 
\HPFP_DRA1N_TMP.ASSOCIATE_COMPONENT\*»HPFP" 

\LPFT_I NLET_PR . SOURCE\*"SYSTEM" 

\LPFT_INLET~PR.SIGMA_NAME\*"LPFT IN PRJ04MF" 

\LPFT_INLET_PR . SENS0R_PID_NUMBER\*"436" 
\LPFT_INLET_PR.NAME\*"LPFTJNIET PR M 
\LPFT_INLET_PR . MEASUREMENT'S I NGLE" 

\LPFT_INLET_PR . GENER I C_NAME\«"P_OUT ,P_IN M 
\LPFT_INLET_PR.ASSOC1ATE_COMPONENT\="F109,LPFT" 

\FUEL_PRESSURANT_I NTER FACE_PR . S I GMA_NAME\* M FL_PR_I NT_PR_104MF" 
\FUEl_PRESSURANT_INTERFACE~PR.SENSOR_PID_NUHBER\="835" ~ 
\FUEL_PRESSURANT_INTERFACE_PR.NAME\*"FUEL PRESSURANT INTERFACE PR" 
\FUE L_PRESSURANT_I NTER FACE_PR . MEASUREMENT \*"SINGtE" 
\FUEL_PRESSURANT_I NTERFACE_PR . GENER 1 C_NAME\*"NotKno«n" 
\FUEL_PRESSURANT_INTERFACE_TMP.SJGMA_NAME\*"FL_PR_INT_T_104MF" 
\FUEL_PRESSURANT_I NTERFACE~TMP . SENSOR_PID_NUHbIr\*"1035" 
\FUEL_PRESSURANT_I NTERFACE_TMP . NAMEWFUEL PRESSURANT INTERFACE TMP" 
\ FUE L_PRESSURANT_I NTER FACE_TMP . MEASUREMENT\*"S INGLE" 

\ FUE L_PRESSURANT_I NTER FACE~THP .GENERIC NAME\*"NotKnown" 

\0PB_PC . SOURCE\*«SYSTEM" 

\0PB_PC . S I GMA_NAME\*"0PB_PC_1 04MF" 

\0PB~PC . SENS0R_P I D_NUM8ER\*"480" 

\OPB~PC . NAME\*"OPB_PC" 

\OPB~PC . MEASUREMENT \*"S INGLE" 

\0PB_PC . GENER I C_NAME\*"P_I N , P_0UT" 
\OPB_PC.ASSOCIATE_CCMPONiNT\*"HPOT,OPB" 

\ FPOV_POS I T I ON . SOURCE \*"S YSTEM" 

\ FPCJV POS I T I ON . S I GMA_NAME\*“ FPOV_ACT_POS 104MF" 

\ FPOVPOS I T I ON . SENSOR_P I D_NUMBER\*“ 1 42" 

\FPOV_POS I T I ON . NAME\*" FPOV POSITION" 

\FPOV~POS I T I ON . MEASUREMENT \*"S I NGLE" 

\FPOV_POS I T ION . GENER I C_NAME\*“POS" 

\FPOV_POSITION. ASSOCIATE COMPONENT\*"FPOV" 

\MCC_LOX_ I N JE CTOR_TMP . SOURCE\="SYSTEM« 

\MCC_LOX_I N JECTOR_TMP . S I GMA_NANE\*"MCC OX INJ T_104MF“ 

\MCC_LOX_I N JECTOR_TMP . SENSOR_P I D_NUMBER\*"595" 
\HCC_LOX_INJECTOR_TNP.NAME\*"MCC~LOX INJECTOR TMP" 

\MCC_LOX_I N JECTOR_TMP . MEASUREMENTS"? INGLE" 

\MCC_LOX_INJECTOR_TMP . GENER I C_NAME\*"T_IN_OX , T_OUT" 

\MCC_LOX_ I NJECTOR_TMP . ASSOC I ATE COMPONENT\*"MCC , MOV" 

\MCC_LOX_ I N JECTOR_PR . SOURCE\*"$YSTEM" 

\MCC_LOX_ I N JECTOR_PR . SI GMA_NAME\*"MCC_OX_I N J_PR_1 04MF" 

\MCC_LOX_I N JECTOR_PR . SENSOR _P I0_NUMBER\*"395" 

\MCC_LOX_ I NJECTOR_PR . NAME\*"MCC~LOX INJECTOR PR" 
\MCC_LOX_INJECTOR_PR.MEASUREMENT\*"SINGLE" 

\MCC_LOX_ INJECT OR_PR . GENER I C_NAME\*"P_I N_OX , P_OUT" 
\MCC_LOX_INJECTOR_PR . ASSOC I ATE_COMPONENT\*"MCC,MOV" 
\POGO_PRE_CHARGE_PR . SOURCE\«"SYSTEM« 

\POGO_PRE_CHARGE_PR . S I GMA_NAME\*"P0G0_PRCHG_PR_1 04MF" 
\POGO_PRE_CHARGE_PR . SENSOR_P ID _NUMBER\*"22 1 " 
\POGO_PRE_CHARGE_PR.NAME\*"POGO_PRE_CAHRGE_PR" 
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\POGO_PRE_CHARGE_PR.MEASUREHENTWSINGLE" 
\POGO_PRE_CHARGE_PR.GENERIC_NAME\="P_PRE_IN" 
\POGO_PRE_CHARGEJ>R.A$SOCIATE_COMPONENT\="POGO" 
\HEAT_EXCHANGER_DS_PR . S I GHA_NAME\»"HX_DS_PR_1 04MF" 
\HEAT_EXCHANGER_OS_PR.SENSOR_PID_MUHBER\*"34" 
\HEAT_EXCHANGERJ)S_PR.NAME\«"HEAT EXCHANGER DS PR" 
\HEAT_EXCHANGER_DS_PR.MEASUREMENT\*"S INGLE" 

\HEAT_EXCHANGER_DS_PR. GENER lC_NAME\*"NotKnown“ 

\HEAT_EXCHANGER_ INTER FACE_PR . 5 1 GNA_NAHE\*“HX _I NT_PR_1 04MF" 
\HEAT_EXCHANGER_I NTER FACE_PR . SENSOR_P I D_NUMBER\=»878" 
\HEAT_EXCHANGER_I NTERFACE_PR . NAME\=“HEAT EXCHANGER INTERFACE PR" 
\HEAT_EXCHANGER_I NTERFACE~PR . MEASUREMENT \*"S I NGLE" 
\HEAT_EXCHANGER_I NTER FACE j>R . GENER I C_NAME\="NotKnown" 
\HEAT_EXCHANGERJNTERFACE_THP.$IGMA_NAME\=“HX_INT_T_104NF" 
\KEAT_EXCHANGER_I NTERFACE_TMP . SENSOfi_PID_NUHBER\="879" 
\HEAT_EXCHANGER_INTERFACE_TMP.NAME\*"HEa7 EXCHANGER INTERFACE THP" 
\HEAT_EXCHANGER_I NTER FACE_tHP .MEASUREMENT \="SINGLE" 
\HEAT_EXCHANGER_I NTER FACE_TMP .GENERIC NAME \*"NotKnown" 
\OPOV_POSITION.SOURCE\«»SYSTEM" 

\OPOV_POS I T I ON . S I GMA_NAME\»"0P0V_ACT_P0S_1 04MF " 

\OPOV_POS I T I ON . SENSORP I ONUMBERN*" 1 40" 

\OPOV_POS I T I ON . NAME\*"OPOV_POS I T I ON" 

\OPOV_POS I T I ON .MEASUREMENT\*"S INGLE" 

\OPOV~POS I T I ON . GENER I C_NAME\«"POS" 

\OPOV_POS I T I ON . ASSOC I ATE_COMPONENT\«"OPOV» 

\HPOP_SPEED . SOURCE\*"SYSTEH" 

\HPOP~SPEED . S I GMA_NAME\="HPOP_SPD_104MF" 

\HPOP_SPEED . SENSOR_P I D_NUMBER\*"2" 

\HPOP_SPEED . NAME\«"HPOP_SPEEO" 

\HPOP_SPEED .MEASUREMENT\«"S I NGLE" 

\HPOP_SPEED . GENER 1C_NAME\>"SPEED , SPEED , SPEED" 

\HPOP_SPEED . ASSOC 1 ATE_CONPONENT\=»HPOP , HPOS , HPOT " 

\LPOP_SPEED2 . SOURCE\«"SYSTEM" 

\LPOP_SPEED2 . S I GMA_NAME\«"LPOP_SPD_1 04MF" 

\LPOP_SPEED2 . SENSORP I D_NUM8ER\*"734" 

\LPOP_SPEED2 . RELATED_TO\*"LPOP_SPEED 1 " 

\LPOP~SPEED2 . NAME\*"LPOP_SPEED2" 

\LPOP~SPEED2 .MEASUREMENT\*"CONST I TUT ION" 

\LPOP_SPEED2 . GENER I C_NAME\*"SPEED , SPEED , SPEED" 

\LP0P_SPEE02 . ASSOCI ATE_COMPONENT\*"LPOP , LPOS , LPOT" 
\HPOP_BAL_CAV_PR_B . SOURCE\*"SYSTEM" 

\HPOP_BAL_CAV_PR_B . S I GMA_NAME\»"HPOP_BCAV_PR_B_1 04MF" 
\HPOP_BAL_CAV_PR_B . SENSORP I D_NUMBER\»“328" 

\HPOP_BAL_CAV_PR_B . RELATED_TO\»«HPOP BAL CAV PR1" 
\HPOP_BAL_CAV_PR_B . NAME\«"HPOP_BAL_CAV_PR_B"~ 

\hpop_bal_cav_pr_b.keasurement\*"const7tution" 

\HPOP_BAL_CAV_PR_B . GENER I C_NAME\«"P_BAL " 

\HPOP_8AL_CAV_PR_B -ASSOC I ATE COMPONENT\«"HPOP" 

\HPOP_BAL_CAV_PR_A . SOURCE\»"SYSTEM« 
\HPOP_BAL_CAV_PR_A.SIGMA_NAME\«"HPOP BCAV PR A 104MF" 
\HPOP_BAL_CAV_PR_A.SENSOR_PlD_NUMBER\»"327" 

\HPOP_BAL_CAV_PR_A .RELATED TO\»"HPOP BAL CAV PR1" 
\HPOP_8AL_CAV_PR_A . NAME\««HPOP BAL CAV PR A«~ 

\hpop_bal_cav_pr_a.measurement\-"const7tution" 

\HPOP_BAL_CAV_PR_A . GENER 1 C_NAME\»"P_BAL" 

\HPOP_BAL_CAV_PR_A .ASSOC I ATE_COKPONENT\«"HPOP" 
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\IPFP_SPEED2 . SOURCE\*"SYSTEM" 
\LPFP_SPEED2.SIGMA_NAME\="LPFP_SPD_104MF" 
\IPFP_SPEED2 . SENSOR_P ID_NUMBER\*"754» 

\IPFP_SPEED2 . REIATED_T0\«"LPFP_SPEED1" 
\IPFP_SPEED2.NAME\«"LPFP_SPEED2" 
\LPFP_SPEED2.MEASUREHENT\*"CONST I TUT ION" 
\LPFP_SPEED2 . GENER I C_NAME\="SPEED , SPEED , SPEED" 
\LPFP_SPEED2.ASSOCIATE_COMPONENT\*"LPFP, LPFS,LPFT" 
\LPFP_SPEED. SOURCE \«“S YSTEM" 

\LPFP~SPEED . S I GMA_NAME\«»LPFTP_SPD_1 04MF" 
\LPFP_SPEED . SENSOR _P I D_NUMBER\="32" 

\LPFP_SPEED .RELATED_TO\*"lPFP_SPEED1 " 

\LPFP_SPEED . NAME\«"LPFP_SPEED" 

\LPFP_SPEED .MEASUREMENT\="CONST I TUT ION" 

\LPFP_SPEED . GENER I C_NAME\»"SPEED , SPEED , SPEED" 
\LPFP_SPEED.ASSOCIATE_CONPONENT\*“LPFP,LPFS,LPFT" 
\HPFP_SPEED2 . SOURCE\*"SYSTEM" 

\HPFP_SPEED2 . S I GMA_NAME\«"HPFP_SPD_1 04MF" 
\HPFP_SPEED2.SENSOR_PID_NUMBER\*"764“ 

\HPFP_SPEED2 . RE L ATED_TO\«"HPFP_SPEED 1 " 
\HPFP_SPEED2.NAME\«"HPFP_SPEED2" 

\HPFP_SPEED2 .MEASUREMENT\*"CONST I TUT I ON" 
\HPFP_SPEED2 . GENER IC_NAME\*"SPEED , SPEED , SPEED" 
\HPFP_SPEED2 . ASSOCI ATE_COHPONENT\=“HPFT , HPFS , HPFP" 
\HPOT_DS_TMP_B . SOURCE\«"$YSTEM" 

\HPOT_OS_TMP_B . S I GMA_NAME\*"HPOT_T_B_104MF" 
\HPOT_DS_TMP_B . SENSOR_PID_NUNBER\*"234» 
\HPOT_DS_TMP_B.RELATED_TO\»"HPOT_DS_TMP1" 
\HPOT_DS_THP_B . NAME\«"HPOT_DS_TMP_B" 

\HPOT_DS_TMP_B . MEASUREMENT \="CONST I TUT ION" 
\HPOT_DS_THP_B . GENER I C_NAME\«"T_OUT , T_I N" 
\HPOT_DS_TMP_B . ASSOC I ATE_COMPOnInT\*"HPOT , 0207" 
\HPOT_DS_TMP_A . SOURCE\*"SYSTEM" 

\HPOT_DS_TMP_A . S I GMA_NAM€\«"HP0T_T_A_1 04MF" 
\HPOT_DS_TMP_A . SENSOR_P ID_NUMBER\*"233 H 
\HP0T_DS_TMP_A.REIATED_T0\*“HP0T DS TMP1" 
\HPOT_DS_TMP_A . NAME\«“HPOT_DS_TMP_A" 

\HPOT_DS_TMP_A . MEASUREMENT \*«CONST I TUT I ON" 
\HPOT_DS_TMP_A . GENER I C_NAME\«"T_OUT , T_I N" 
\HPOT_DS_TMP_A.ASSOCIATE_COHPONENT\*"HPOT,O207" 
\HPFT_DS_TMP_A . SOURCE\*"S YSTEM" 

\HPFT_DS_TMP_A . S I GMA_NAME\«"HPFT_T_A_104MF» 
\HPFT_DS_TMP_A . SENSOR_PID_NUMBER\«"231 " 
\HPFT~DS~TMP~A. RELATED TO\»“HPFT DS TMP1" 
\HPFT_DS_TMP_A . NAME\«"HPFT_DS_TMP_A" 

\HPFT_DS_TMP_A . MEASUREMENT \«“CONST I TUT ION" 
\HPFT_DS_TMP_A . GENER I C_NAME\»"T_OUT , T_I N" 
\HPFT_DS_TMP_A . ASSOC! ATE_COMPONENT\*"HPFT , F 1 1 1 » 
\HPFT_DS_TMP_B . SOURCE\»«SYSTEM" 

\HPFT_DS_TMP_B . S I GNA_NAME\»"HPFT_T_B_1 04MF" 
\HPFT_DS_TMP_B . SENSORP I D_NUMBER\»"232" 
\HPFT_DS_TMP_B.RELATED_TO\»"HPFT DS TMP1" 
\HPFT_DS_TMP_8 . NAME\*"HPFT_DS_TMP_B" 

\HPFT_DS_TMP_B . MEASUREMENT\»"CONST I TUT I ON" 
\HPFT_OS_TMP_B .GENER I C_NAM£\«"T_OUT ,T_IN" 
\HPFT_DS_TMP_B . ASSOC I ATE_COMPONENT\="HPFT .Fill" 
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\LPOP_SPEED . SOURCE\*"SYSTEH" 

\IPOP_SPEEO . S I GMA_NAME\*"LPOTP_SPD_1 04MF" 
\LPOP_SPEED.SENSOR_PID_NUMBER\*"30" 

\LPOP_SPEED . ^ELATED_TO\*»LPOP_SPEEO 1 « 

\LPOP_SPEED . NAME\*"LPOP_SPEED" 

\IP0P_SPEED . MEASUREMENT \* "CONST I TUT ION' 1 
\LPOP_SPEED . GENER I C_NAME\*"SPEED , SPEED , SPEED" 
\LPOP_SPEED . ASSOC I ATE_COMPONENT\*»LPOP , LPOS , IPOT" 
\HPFP_SPEED.SOURCE\*"SYSTEH" 

\HPFP_SPEED . S I GMA_NAHE\*"HPFTP_SPD_1 04MF" 
\HPFP_SPEED.SENSOR_PID_NUMBER\="260" 

\HPFP_SPEED . RELATED_TO\="HPFP_SPEED 1 " 

\HPFP_SPEED . N AMEX* " HP F P_SPE ED" 

\HPFP_SPEED .MEASUREMENT\="CONST I TUT ION" 
\HPFP_SPEED . GENER I C_NAME\*"SPEED , SPEED , SPEED" 
\HPFP_SPEED.ASSOCIATE_COMPONENT\=»HPFT,HPFS,HPFP" 
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\FPB.NAHE\="FPB" 

\FPB . GAS JXIT\« H HPFT» 
\FPB.FUEL_IN\** , F110" 
\rPB.OX_IN\* M FPOV" 

\ FPB .ASSOC I ATE_PARAMETERS\="FPB_PC" 
\FPB . GENER I C_PARAMETERS\="pout" 
\OPB.NAME\= M OPB" 

\OPB.GAS_OUT\="HPOT H 
\OPB. FUEL_IN\*"F108" 

\OPB . OX_ I N \*“OPOV" 

\OPB. ASSOC I ATE_PARAMETERS\="Not known" 
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\F101.NAME\="F101" 

\F101 .MEDIUM_OUTPUT\="HPFP" 

\F101 .MEDIUM_INPUT\="LPFP" 

\F101 .MEDIUM\*“FUEL" 

\F101 . ASSOCI ATE_PARAMETERS\= M FUEl F10W,LPFP_DS_TMP,LPFP DS PR" 

\F101 .GENERIC_PARAMETERS\="Vout,Tin,pin" 

\F 1 02 . NAME \=" F 1 02" 

\F1 02 .MED IUM_OUTPUT\="MFV" 

\F102.MEDIUM_INPUT\*"HPFP" 

\ F 1 02 . MED I UM\=" FUEL " 

\F102.ASSOCIATE_PARAMETERS\="HPFP DS_PR,HPFP DS_TMP M 
\F102.GENERICJ>ARAMETERS\=''pin,Tin» “ 

\F 1 07. NAME\""F1 07" 

\F 1 07 . MED I UM_OUTPUT\="H 1 03 " 

\ F 1 07 . MED l UM~I NPUT\="M20 1 " 

\ F 1 07 . MED I UM\*" FUEL " 

\F107.ASSOCIATE_PARAMETERS\="NotKnoun" 

\F108.NAME\*"F108" 

\F108.MEDIUM_OUTPUT\s»OPB" . 

\F108. MEDIUM jNPUT\*«M103" 

\F108.MEDIUM\«"FUEL“ 

\F108.ASS0CIATE_PARAMETERS\*»NotKnown» 

\F109.NAME\="F109" 

\F109.HEDIUM_OUTPUT\*"LPFT" 

\F 1 09 . MED I UM_ I NPUT\*"MCC COOLING" 

\F109.MEDIUM\»"FUEL" 

\ F 1 09 . ASSOC I ATE_PARAMETERS\="MCC CLNT DS PR,MCC CLNT DS TMP.LPFT INLET PR" 
\F109 . GENER I C_PARAMETERS\*"pi n , T i n, pout"” 

\F110.NAME\*"F110" 

\F110.HED1UM_OUTPUT\»"FPB" 

\F110.MEDIUM~INPUT\»"M103" 

\F110.MEDIUH\=“FUEL" 

\F1 1 0 . ASSOC I ATE_PARAMETERS\="NotlCnown M 
\F111.NAME\="FlTl" 

\F1 1 1 . MED IUM_OUTPUT\*"MCC" 

\F111.MEDIUMJNPUT\»«HPFT" 

\F111 .MEDIUM\«"FUEL" 

\F111.ASSOCIATE_PARAMETERS\*"HPFT DS TMP1“ 

\F1 1 1 . GENER I C_PARAMETERS\="T i n“ 

\O206 . NAME \*"O206" 

\0206 . MED I UM_OUTPUT\«" FPOV" 

\O206 .MED I UM j NPUT\>«M1 OS " 

\0206 . MED I UM\«"OX" 

\0206.ASSOCIATE_PARAMETERS\*"PBP_DS TMP,PBP_DS PR" 

\0206 . GENER I C_PARAMETERS\*"pi n, pout" 
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\LPFP.NAME\= M LPFP H 

\lPFP.MEDIUH_0UTPUT\= M F101 ,, 

\LPFP. MED I UM j NPUT\* ,I FUEL_TAN)C H 
\LPFP. MED IUM\* M FUEL" 

\IPFP .DIRECT!ON\* M IN N 
\lPFP.COUPLED_TO\» M LPFT« 

\LPFP.ASSOCIATE_PARAMETERS\*"ENG_FUEL_INL£T_PR,ENG_FUEL_IfillET_TMP,LPFP_$PEEDl , LPFP_DS_PR , LPFP_DS_TMP M 
\LPFP . GENER I ^PARAMETERSX^pi n jin , omega , pout , Tout " 

\HPFP.NAME\* M HPFP** 

\HPFP.MEDIUM_OUTPUT\="F102" 

\HPFP. MEDIUM jNPUT\='*F101» 

\HPFP.MEDIUM\* M FUEL M 

\HPFP.DIRECTION\« M IN» 

\HPFP. COUPLED_TO\* M HPFT" 

\HPFP.ASSOCIATE_PARAMETERS\= H HPFP_DS_PR, FUEL_FL0W,HPFP_$PEED1 , HPEP^DS^THP* 
\HPFP.GENERIC_PARAMETERS\=»pout,Vin, omega. Tout' 1 
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\FUEL_TANK.NAME\="FUEL_TANK" 

\FUEL_TANK.MEDIUM_OUTPUT\="LPFP" 

\FUEL_TANK.MEDIUH\««FUEL“ 

\FUEl_TANK.ASSOCIATE_PARAHETERS\*"HPFP SPEED 1 , FPB PC,HPFT DS_TMP1" 

\ FUE L_T ANK . GENER I C_PARAMETERS\*'*omega , p i n. Tout 1 » 

\FUEl_TANK.ASSOCIATEJ>ARAMETERS\* M ENG_FUELJNLET_PR,ENG_FUEl_INLET_THP" 
\FUEL_T ANIC . GENER I C_PARAMETERS\="pout , T out" 
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\FUEL_TANK.NAME\="FUEl_TANK" 
\F111 .NAME\="F1 1 1" 
\0206.NAME\= M 0206" 

\OPB . NAME \="OPB M 
\M101 .NAME\*"H101" 


Sep 20 13:48 1991 trisplit Page 1 


\M1 02 . NAME\="M1 02" 

\M1 02 . MED I UM_OUTA\="MCC_COOL I NG" 

\M1 02 . MED I UH_OUTB\="NOZZLE_COOL I NG" 

\M1 02 . MED IUM_OUTC\»"CCV" 
\M102.MEDIUM_IN\*"MFV" 

\M102.MEDI UM\=" FUEL" 

\M102 . ASSOC I ATE_PARAMETERS\="Notlcnown" 
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\M201.NAME\="M201" 

\M201 .MEDIUM_OUT\="F107 ,, 
\M201.MEDIUHJNA\*"NOZZLE_COOUNG'' 
\M201 .MEDIUM JNBWCCV" 

\M201 .MEDIUMV*"FUEL H 

\M201 . ASSOC I ATE_PARAMETERS\="Not knoun" 
********** 
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\M101.NAME\»»M101" 
\H101.MEDIUM_OUTA\»"HPOT_COOUNG" 
\M101.MEDIUM~OUTB\= ,, HPFT~COOUNG M 
\M1 01 . MED I UM~ 1 N \« M LPFT" ~ 

\M101 . MED IUN\«" FUEL" 

\N101 .ASSOCIATE_PARAMETERS\ z "Notknown" 

\M103.NAME\«“M103" 

\M103.ME0IUM_OUTA\*"F108" 

\H1 03 .MED I UM~OUTB\«"F1 1 0 M 
\M103. MEDIUM jN\«"F107" 

\M1 03 . MED IUM\«" FUEL " 

\M1 03 . ASSOC I ATE_PARAMETERS\*"Not known" 


